Author
Alec Powell
Master Principal Sales Engineer
Product2 min Read
SingleStoreDB 201: Tips & Tricks Webcast
In a recent webcast , we shared tips and tricks for understanding SingleStore, best practices for implementation, and demoed SingleStore…
Read Post
Engineering
Database Multi-Tenancy in the Cloud and Beyond
In today’s wave of Enterprise Cloud applications, having trust in a data store behind your software-as-a-service (SaaS) application is a must. Thus, multi-tenancy support is a critical feature for any enterprise-grade database. This blog post will cover the ways to implement multi-tenancy, and best practices for doing so in SingleStore.
As customer table sizes grow, you will need to scale out your multi-tenant database across dozens of machines. To support rich analytics about your customers or as a feature for your end customers, you will want a solution that scales without bogging down reporting capabilities. Successful multi-tenant platforms require massive scalability, online patching/upgrading, the ability to process high volumes of data ingestion, and deliver high performing complex analytics.
SingleStore delivers the requirements for a multi-tenant platform through the rich analytical and transactions capabilities of SQL. SingleStore also scales to hundreds of nodes in a cluster leveraging shared nothing commodity hardware. Combining these multi-tenant capabilities with extreme data ingestion makes SingleStore a truly unique product to deliver SaaS data.
Most database architectural patterns for multi-tenant applications follow one of three approaches:
Separated DatabaseSeparate SchemaShared Schema
If isolation requirements are not accounted for early in application development, retrofitting them can be even more costly. In our conversations with customers, scale is often the driver. Let’s delve into the three models:
1) Separated Database
Read Post
