ormDB for Multi-Tenant Platforms
ormDB provides database-level multi-tenant isolation through row-level security policies enforced on every query. Combined with safe migrations (A-D grading) for shared schemas and query budgets to prevent noisy-neighbor problems, ormDB is purpose-built for multi-tenant platforms.
The multi-tenancy challenge
Multi-tenant platforms share database infrastructure across tenants. The two critical requirements are: tenant data must never leak, and one tenant must never impact another’s performance.
Traditional approaches rely on application-level WHERE clauses for isolation — a single missed filter means a data breach. See how this compares to PostgreSQL’s RLS approach. And without query budgets, a single heavy tenant can degrade performance for everyone.
ormDB’s approach
ormDB is a relational database engine that enforces multi-tenancy at the database level. Row-level security policies are part of the schema, not your application code. Every query — including graph fetches across relations — automatically respects tenant boundaries.
Query budgets prevent noisy-neighbor problems. See the performance optimization guide for details. Set limits on max depth, fanout, total rows, and execution time per query. No tenant can run a query that impacts the shared infrastructure.
Safe migrations with A-D grading ensure schema changes to the shared database never cause unexpected downtime. You know exactly what a migration will do before you run it.
Isolation that lives in the schema
Instead of relying on developers to remember a WHERE tenant_id = ? on every query, you declare the rule once as a policy and the engine enforces it everywhere:
policy tenant_isolation on Account, Project, Member {
filter: tenant_id == session.tenant_id
}
# The application just fetches; the policy is applied automatically
graph_fetch Project (status = "active") {
name, status,
members { role, user { name, email } }
}Every graph fetch, including the members and user hops, is scoped to the current tenant. A missing filter can no longer cause a cross-tenant leak because there is no filter to forget.
Choosing shared-schema ormDB vs the alternatives
ormDB is in Alpha (v0.1.0). Its shared-schema-plus-RLS model avoids the per-tenant database sprawl and the app-layer filtering risk that traditional stacks carry, and it compares favorably to bolting RLS onto PostgreSQL or a managed platform like Supabase. For production platforms that need proven multi-tenant tooling today, PostgreSQL RLS remains the mature option — ormDB is the strongest fit when you want isolation, safe shared-schema migration, and noisy-neighbor protection built into one engine. See the multi-tenant best-database guide for the full decision framework.
Frequently Asked Questions
How does ormDB isolate tenant data?
ormDB's row-level security policies are enforced at the database level, not the application level. Every query automatically filters by tenant context, making data leaks between tenants structurally impossible.
Can ormDB handle thousands of tenants?
Yes. ormDB uses a shared-schema multi-tenant model with row-level security. There's no per-tenant database overhead. Query budgets prevent any single tenant from consuming excessive resources.
Does row-level security apply to graph fetches too?
Yes. Policies are enforced by the engine on every access path, including relations traversed inside a graph fetch. Loading a tenant's account with its projects and members cannot leak another tenant's rows through a relation, because the policy is checked at each hop rather than only at the root query.
How do you migrate a shared multi-tenant schema safely?
Run migrations through ormDB's A-D grading. Because all tenants share one schema, a bad ALTER would affect everyone at once — grading flags Grade C and D changes before they run so a shared-schema change never causes an unplanned outage across the whole tenant base.
Can admins run cross-tenant queries?
Yes. Policies are driven by session context, so a privileged admin or internal-analytics context can be granted a policy that spans tenants, while ordinary tenant sessions remain strictly isolated. The isolation rule lives in the schema, not scattered across application code.