You built for one customer. Now you have ten. Everyone can see everyone's data.
A single-tenant application stores all users in one namespace. A multi-tenant application separates organizations from each other. Adding multi-tenancy to a single-tenant application is a major refactor — understanding what it involves and the right path to doing it safely.
Application built for one customer (or without organization separation) that now needs to serve multiple separate organizations without data bleeding between them
Adding multi-tenancy to an existing single-tenant application is a significant data model change. The path depends on how the current data model is structured.
The multi-tenancy data model patterns:
Shared database, shared schema (with tenant_id):
All tenants share the same Postgres database and tables. Every relevant table has a tenant_id (or organization_id) column. All queries include WHERE tenant_id = :current_tenant_id. Row Level Security enforces this at the database level.
Most appropriate for most SaaS applications. Lower infrastructure cost; complex query for every table to get right.
Shared database, separate schemas:
Each tenant gets their own Postgres schema (tenant_1.users, tenant_2.users). More isolation than shared tables; still one database instance. Database migrations must be applied to every schema.
Appropriate when tenants need schema customization or when compliance requires stronger isolation than RLS.
Separate databases per tenant: Each tenant has their own database instance. Maximum isolation; maximum infrastructure complexity. Appropriate for high-compliance contexts (healthcare, financial services, government).
The migration from single-tenant:
- Add
tenant_idcolumn to all relevant tables - Migrate existing data to a "default" tenant
- Add RLS policies
- Update all application queries to filter by tenant
- Add organization/tenant management (create, invite, switch orgs)
- Test data isolation thoroughly before onboarding new tenants
The common risk: missing a table or query that doesn't filter by tenant, leading to data leakage. Comprehensive testing of the tenant isolation is required.
Multi-tenant data architecture with complete isolation between organizations — each tenant sees only their data, and the isolation is enforced at the database level
Data model migration
adding tenant_id to all relevant tables
Row Level Security
database-level enforcement
Organization management
create org, invite members, switch organizations
Isolation testing
verifying data doesn't leak between tenants
One honest number to start.
Fixed-scope, fixed-price. The number below is the starting point — final scope is built from your brief.
Multi-tenant data architecture with complete isolation between organizations — each tenant sees only their data, and the isolation is enforced at the database level
Three steps, every time.
The same repeatable engagement on every project. No surprises, no mystery, no billable ambiguity.
Brief & discovery.
We send you questions, then get on a call. Output: a written scope with every step, feature, and integration listed.
Build & ship.
Fixed schedule, weekly reviews. No scope creep unless you change the scope — and if you do, we reprice it transparently.
Warranty & retainer.
30-day warranty on every launch. Most clients stay on a monthly retainer for ongoing features and maintenance.
Why Fixed-Price Matters Here
Multi-tenancy migration scope is auditable from the data model. Scoped based on the number of tables and existing query complexity.
Questions, answered.
With careful migration (adding nullable columns first, backfilling, then making required), yes. Zero-downtime database migrations require specific patterns.
A table without tenant filtering could return data from other organizations. This is a data leak that affects all queries against that table. Thorough testing of every data access path is required.
Tell Ryel about your project.
Describe what you’re building and what outcome you need. You’ll have a written, fixed-price scope within the week.