These numbers make more sense on hardware from 5 years ago (to be fair, what they were dealing with), but postgres, on modern consumer hardware (Yes, consumer! Ex: KC3000 + Ryzen 7950x), already does over 50k QPS without being overburdened. You could probably squeeze out 100k QPS with faster NVME's.
That's like 10 tall servers for their peak QPS? (500k QPS on slide 19)
Lots of natural sharding points here too: company, game, usage of data, etc.
This is assuming you avoid or go light on expensive features like foreign keys (as Vitess already does).
The "scale magic" in Spanner (Big Table) inspired DB's are just hidden automation of traditional sharding-
CockroachDB: Sharded indexes, then runs map reduce for you.
Scylla/Cassanda: Sharded indexes again, but more limitations for speedups: Eventually consistent. You don't have fast delete- only update (discord uses tombstones). JOIN's are "in app" only.
Vitess: Proxy that dismantles/routes your query to the correct server. This scales, but is eventually consistent. JOIN's on co-located data, or "in app".... in simple terms, Vitess is like an externally managed "in app" query parser/router.
That's like 10 tall servers for their peak QPS? (500k QPS on slide 19)
Lots of natural sharding points here too: company, game, usage of data, etc.
This is assuming you avoid or go light on expensive features like foreign keys (as Vitess already does).
The "scale magic" in Spanner (Big Table) inspired DB's are just hidden automation of traditional sharding-
CockroachDB: Sharded indexes, then runs map reduce for you.
Scylla/Cassanda: Sharded indexes again, but more limitations for speedups: Eventually consistent. You don't have fast delete- only update (discord uses tombstones). JOIN's are "in app" only.
Vitess: Proxy that dismantles/routes your query to the correct server. This scales, but is eventually consistent. JOIN's on co-located data, or "in app".... in simple terms, Vitess is like an externally managed "in app" query parser/router.