A test suite with one tenant passes the export query that returns both customers' invoices

The unfiltered SELECT is the version that is easy to picture. The same omission turns up in a lookup by ID, an update and a delete ^[6]. A globally unique invoice ID keeps two customers' records from colliding, and it does not establish that the current user may touch the row it names ^[7]. "I wouldn't build tenant isolation around everyone remembering a filter," the author wrote ^[8].

Two questions are being kept apart here. Tenant isolation asks which organization's data a request can reach; permissions ask whether a member of that organization may view invoices, invite teammates or change settings, and the post says you need both ^[24]. The model assumed throughout is one tenant per user, with several users per tenant ^[23].

Schema-per-tenant is one PostgreSQL database holding a separate schema per customer organization, where a schema is a named container for database objects and each tenant gets its own set of business tables inside it ^[20]. An unfiltered SELECT against those tables can only return rows that live in the schema the connection resolved to. Correctness moves off every predicate in every query and onto one routing decision per request. The post describes itself as an architecture walkthrough whose examples illustrate the design and are not a complete implementation ^[21].

For a B2B SaaS with many workspaces, broadly the same data model and a small engineering team ^[11], I would make the same call. A boundary you can see in the schema list is easier to audit than a predicate you have to find in every query anyone adds later.

The cost argument against separate databases lands in application code. Include the JDBC or JPA starter and Spring Boot hands you HikariCP whether you asked for it or not ^[14]. Configure a minimum of five idle connections in each of 1,000 active pools and those pools are being asked to hold 5,000 idle connections in total ^[16]. The author calls that a configuration example and not an unavoidable connection count ^[17].

Each pool carries its own connection objects, housekeeping and lifecycle, and holding idle connections open across hundreds of mostly inactive tenants wastes resources ^[25]. For any of that to bear on your deployment, your tenant count has to resemble the example's; a few dozen workspaces on one Postgres do not produce a pool problem, and the case for the schema boundary then rests entirely on where isolation is enforced. In pool terms the boundary is cheap: the same 1,000 tenants that need 1,000 pools as separate databases need one data source when they are schemas in a single database ^[22].