Multi Tenant Data Isolation Patterns
Everything I do professionally is around helping engineers create amazing applications that are both secure and reliable. That’s why I build engineering tools and educational content that simplify application security.
Throughout my career, I have performed security audits for private and open-source projects, and have found critical vulnerabilities in Google and Mozilla products. I have also taught security to hundreds of engineers and students, while I have also been an external lecturer and Ph.D. candidate in computer science at the Technical University of Denmark.
Here are some of the things I’m working on right now:
- Developing a tool 🛠️ that helps software engineers build applications which comply with privacy requirements
- Creating weekly educational content on application security using comic art 🦇
- Creating a blog 📝 on security at securingbits.com
If you’re interested in learning more about application security, I’d love to hear from you. Feel free to send me a message, and make sure to follow me so I can make security easy for you 🙂
If you're building a multi-tenant SaaS business, data isolation can be challenging.
Here are four common design patterns with their tradeoffs:
1. Server Isolation: each tenant's database is hosted on separate servers. This provides strong separation between tenants but can be resource-intensive and costly due to increased infrastructure requirements.
2. Database Isolation: tenants share the same server but have dedicated databases within it. It offers better scalability compared to server isolation while still providing substantial separation of data at the database level.
3. Schema Isolation: tenants coexist in a single shared database instance using different schemas. The tenancy logic resides in the application, deciding which schema to access data from. This approach requires careful management as schema changes may impact all tenants.
4. Row Isolation: tenants coexist in a single shared database and each table row is associated with a tenant ID. The tenancy logic resides in the application, deciding which row to fetch data from based on the tenant. This approach provides the least data isolation.
