(Ozgun from Citus) Yup, two good points. When you use this model, Citus guarantees ACI* and T for transactions that are scoped to shards on one machine. It al

(Ozgun from Citus) Yup, two good points. When you use this model, Citus guarantees ACI* and T for transactions that are scoped to shards on one machine. It also handles auto-failover. On one big customer being much bigger than the other, two notes. I completely agree that this could happen; we in fact find that this is more the norm than the exception. On its practical implications, we find that it matters less when you have 100+ customers/tenants. Most multi-tenant apps' data follow a Zipf distribution. In other words, if you're running on single Postgres and have 10K tenants, the largest tenant has around 2-3% of the data. When you follow this sharding scheme, it gives you the opportunity to scale to 50x of where you're today. I believe Salesforce and Google F1 are using a similar approach to sharding their multi-tenant database + the tenant isolation feature Craig mentioned below. Then again, I haven't personally worked on these databases and I'm happy to update my comment accordingly. https://www.citusdata.com/blog/2016/10/03/designing-your-saas-database-for-high-scalability/ https://www.citusdata.com/blog/2016/10/03/designing-your-saa...