Short answer
The foundation of a multi-tenant SaaS architecture is keeping the tenant context intact at every layer of the application: session, query, file path and background job included. Data placement (shared schema, separate schema, separate database) is chosen by operational, cost and isolation needs; there is no single right answer.
The tenant boundary
Customer identity must remain consistent throughout the application, from sessions to database queries, file paths and background work.
Data placement
Shared schemas, separate schemas and separate databases have different operational, cost and isolation tradeoffs. No single model fits every product.
Permissions and subscriptions
A user’s role and a customer’s plan entitlements are different concepts. Validate both on the server; hiding a feature in the interface does not prevent access.
Testing and operations
Test that customers cannot access another tenant’s records, files or reports. Preserve tenant context in usage metering, queues and monitoring. Base scaling decisions on actual load.
The balance between data placement options
A shared schema is the cheapest and easiest to operate but depends on the tenant identifier being applied correctly in every query. A separate schema or database gives stronger isolation and per-customer backup but increases operational and migration load. Your customer profile, legal requirements and team capacity decide.
A practical evaluation exercise
Test the same user role in two customer accounts. Check tenant isolation independently for lists, search, downloads, exports and background jobs. Enforce scope on the server rather than relying on screen filters. Consider restoring one customer from backup and deleting customer-specific data before committing to the storage model. We apply these decisions in our own product, LiftOfis.
Frequently asked questions
Two questions we are often asked on this topic.
Should I keep customer data in separate databases?
It depends. If you have a few large customers that demand strong isolation, a separate database may make sense; for many small customers a shared schema is usually more suitable. Our SaaS architecture and technical consulting service assesses this decision for your customer profile.
How do I verify that one customer cannot reach another customer's data?
Test the customer boundary separately in listing, search, file download, export and background jobs, and do not leave authorisation to a UI filter alone. Automating these tests catches regressions in later changes.
Sources and further reading
