Multi-tenant data isolation: schema-per-tenant vs. database-per-tenant
How Salus keeps one laboratory's data out of another's reach on shared infrastructure, and why the isolation boundary differs by database engine.
Two engines, two isolation grains
Salus is dialect-neutral by design: a deployment runs on Postgres or Snowflake behind the same application code, chosen at deploy time. The tenant boundary isn't the same shape on both. On Postgres, each laboratory gets its own schema within a shared database. On Snowflake, each laboratory gets its own database, since Snowflake's privilege model makes database-level ownership simpler to reason about and audit than per-schema grants.
Either way, every laboratory's tables, roles, and data live in a boundary that belongs to that laboratory alone. A tenant's own administrator gets full developer access inside that boundary; creating a new one is a platform action, done at provisioning, not something a lab does to itself.
What this means for a security review
If your security team is asking 'can lab A ever see lab B's rows,' the honest answer is: not through a shared table with a tenant-id column that a bug could mis-scope. Isolation is enforced at the schema or database boundary itself, which is a stronger guarantee than row-level filtering, and it's the same architecture whether the deployment is on Postgres today or Snowflake as the system of record.
See it in your laboratory's context.
Explore the live demo, no login and no request form.