Sharding based on customer is an attractive way to get to shards, potentially with minimal interference in ops or data model, but truly sucks when your biggest customers don’t fit on one shard anymore.
Hi Sugu!
I wouldn’t say that killed my first startup, but it certainly didn’t help.
Database like CockroachDB and TiDB help here.
You can easily buy a machine with several TB of RAM, several hundreds of TB of SSDs in RAID giving you millions of IOPS, quad-socket 256 cores. How likely is it that a single machine cannot handle a single customer?
You either need an enormous client base or are doing something very specialized that requires tons of memory or cpu per customer.
I would think 99% of all internet companies could likely handle everything on a single massive machine, or two, for redundancy. Assuming they were somewhat optimized.
As your database gets into tens or hundreds of TBs, now backups and restores take hours or days to complete. Any DR scenario becomes an existential threat.
For large tables, schema changes can take weeks. This often results in developers doing their own custom table sharding strategies, even though they might still be on a single machine.
I'm not saying that you can't architect around these problems, but operating a db at massive scale on a single machine isn't the obvious win that it seems to be.
> Each keyspace is a logical collection of data that roughly scales by the same factor — number of users, teams, and channels. Say goodbye to only sharding by team, and to team hot-spots!