The document discusses multi-tenancy in PostgreSQL, highlighting three architectural approaches: shared database with shared namespace, separate databases, and shared database with separate namespace. It covers practical considerations such as testing with schemas, migrating multiple schemas, and managing background jobs by passing schema names. The document provides references to resources and tools like the Apartment and Storey gems to aid in implementing these strategies.

2. Multi-tenancy
with PostgreSQL

3. Requirements

10. Three ways
bit.ly/msn-multitenant-arch

11. Shared Database, Shared Namespace

12. Separate Databases

13. Shared Database,
Separate Namespace

14. has
schemas

15. has
namespaces

16. Guy Naor on Multi-tenancy
http://bit.ly/guy-naor-multitenant-2009

17. App

19. carding.app.com/products/1-grapes

20. SET SEARCH_PATH = 'carding'

21. 'carding'
SELECT * FROM products
where id = 1;

22. Common Tables

23. "public"

24. 'carding'
SELECT * FROM public.invoices
where tenant_id = 1;

25. Apartment
github.com/bradrobertson/apartment

28. bob.sql
carding
alice.sql

29. carding

30. carding assimo

31. assimo

32. Storey
github.com/ramontayag/storey

33. Gotchas

34. Problem: Testing
● transactions do not play well with
schemas

35. Answer: Testing
● in tests, treat the public schema as a
tenant

36. Problem: Migrations
● migrate every schema

37. Answer: Apartment/Storey
● loops through the namespaces and
migrates each one

38. Problem: Background Jobs
● how do the workers know which
schema contains the data?

39. Answer: Pass schema name
● Pass the schema name along with the
rest of the job arguments

40. Questions?