For technical readers.
At Fortress, we allow SaaS companies to manage a multi-instance database architecture through a single interface. Here is an example of what a multi-instance architecture looks like:
For many, it seems that supporting a multi-instance database architecture is unnecessary: a single-shared database with Row-Level Security is sufficient to provide isolation for all customers.
In this blog, I want to share why we believe that supporting a multi-instance database architecture will soon become a necessity for the growing SaaS company.
Some initial definitions:
When talking about database isolation for multi-tenant SaaS, a few terms are generally used: db-per-tenant, schema-per-tenant, and row-level security (RLS).
Db-per-tenant is often even more ambiguous as in certain contexts (such as Postgres), it mostly refers to logical database isolation in a shared Postgres instance, while in other contexts, it refers to database instance-level isolation (for example, SQLite).
We refer to multi-instance as a catchall term for any architecture that includes multiple database instances. For example, it can refer to a hybrid architecture consisting of shared or dedicated instances and an architecture consisting of a DB instance per tenant.
These are all examples of multi-instance architectures that we’ve seen SaaS companies use:
- SMB customers are isolated using RLS, while enterprise customers get their own dedicated database instances.
- SMB customers are in separate logical databases on shared clusters, while enterprise customers are on dedicated database instances.
- All customers are on shared database instances, but instances are deployed in different geographical locations.
- All customers get their own dedicated database instances.
We support all of these use cases to make it easy for SaaS companies to transition to our platform.
So why not just one shared database?
We have spoken to large SaaS companies that still use a shared database instance for all of their customers and some sort of logical isolation.
The problem is not with a single shared database itself; RLS is quite secure if it is set up correctly (albeit it arguably lacks performance at scale). Rather, the problem is with the inherent DevOps that occurs once a second database instance is (inevitably) required: how to handle different database connections, propagate schema migrations across these databases simultaneously, tenant management across databases, etc.…
Trends in regulation and concerns in data privacy have made dealing with multiple database instances a necessity for many SaaS companies. GDPR and other local regulations surrounding data sovereignty make it such that the geographical location where data is stored is incredibly important, necessitating separate database instances.
Multi-instance database architecture, split geographically to ensure GDPR compliance.
Further, the rise of AI-based SaaS have made it so that buyers care more about data isolation as they are giving up more of their sensitive internal data to 3rd party vendors. While isolated database instances have been a standard for buyers of SaaS in certain regulated industries, such as Finance, Healthcare, and defense, we have seen this become a growing standard for selling to enterprises in general, with many including this as a requirement in security questionnaires.
Even for customers where dedicated databases are not explicitly required, offering a dedicated database instance is often a way to show enterprise clients that you take security seriously.
So, should you support a multi-instance architecture?
At Fortress, we give SaaS companies the flexibility to offer fully isolated database instances without the additional DevOps this usually requires.
We abstract away the underlying complexity so that developers can interact with a fleet of databases through just the ‘tenant-id.’ Fortress manages schema migrations across database groups and provides a simple interface for tenant-management.
If you are curious to learn more about what we do and how we can help you close more enterprise clients with just a few changes to your code, schedule a call with our founders!
Appendix
Beyond regulations and requirements, there are also inherent advantages of offering a dedicated database:
Performance:
- No noisy neighbor problem and scale database instance individually for the customer
- Ability to deploy a database closer to the customer to reduce read latency (or even on a customer’s private cloud)
Security:
- Inherent network isolation (this is especially important as there are many use-cases now with AI SaaS that involve bi-directional syncs to customer’s internal DB)
- No shared database resources, even logical db-per-tenant level isolation, still share resources between tenants, which might still enable tenant-jacking.
Simplified Compliance:
- Deletion of tenant data, if they churn, is simplified. This is harder with RLS as SaaS must go back and delete a specific tenant’s data from all the backups. By fully isolating an instance, this becomes easier.
- Data can be easily handed over to customers if they churn.
Customizability:
- Custom schemas for larger enterprise customers