How we keep your data truly isolated from other tenants

Multi-tenancy is the default architecture for SaaS. Multiple customers share the same application, the same database infrastructure, and (usually) the same database. The question is: how isolated are they from each other?

Three common approaches

• Shared table with tenant_id: Every record has a tenant_id column. A bug in a WHERE clause can expose another tenant's data.
• Separate databases: Each tenant gets their own database. Simple isolation, but expensive and operationally complex.
• Separate schemas in one database: Each tenant gets their own Postgres schema. Strong isolation without the operational overhead of separate databases.

Why we chose schema-level isolation

Komilfo uses a Postgres schema per tenant. When you sign up, we provision a new schema (e.g. tenant_apex_ems) with a complete copy of our application tables. Your data never shares a table with another organisation's data.

Schema isolation means a single missing WHERE clause cannot expose another tenant's records. The isolation is architectural, not just policy.

How it works in practice

Every API request carries a tenant context — resolved from the JWT, domain, or API key. Our NestJS middleware uses this context to set the Postgres search_path to the correct schema before executing any query. The application code doesn't need to know about tenancy — the schema handles it.

The tradeoffs

Schema isolation adds complexity: migrations must run across every tenant schema, cross-tenant analytics require aggregation at the application layer, and provisioning a new tenant is a real operation (not just inserting a row). We've invested in tooling to handle all of these — but it's worth naming the costs.

For healthcare, legal, and financial customers who ask "where does my data live and who can see it?", the answer with schema isolation is straightforward: in your schema, and only your application users with valid credentials can access it.