4 ms·

Everything is simple when you're starting out. Over time, you'd see that users can have wildly different load patterns, which will affect how you scale and shar

Everything is simple when you're starting out. Over time, you'd see that users can have wildly different load patterns, which will affect how you scale and shard your database over time. It's a huge pain to manage and grow.

zepolen 6y ago
It's way easier to scale a shared app/db, anyone who tells you different hasn't had to do devops. Rule No. 1, never shard by account_id, Pareto is just waiting you kick you in the ass. Always shard by whatever gives the best distribution of workload. There are more rules of course.
- sb8244 6y ago
  I've always considered data isolation as the #1 priority when it comes to tenancy. Does that mean that the sharding should defacto be done on the tenant ID?
  - pietherr 6y ago
    You shard for load distribution. If data isolation is #1 priority, use separate tables, schemas, database instances.
    - zepolen 6y ago
      Separate disks, separate machines hell even separate networks, proper data isolation can be super expensive to do right.