[mu53]

Seriously, a naive database sharding algorithm could be implemented in a week or so by a competent dev.

A company like figma (billions in revenue) putting a small team to implementing a database sharding solution for an un-implemented use case (RDS, not just postgres). AND open sourcing it creating a value for the community is a net-good for the industry.

[harisund1990]

Sharding is the easy part. Eventually you need to implement distributed transactions, taking a consistent backup across shards, PITR, resharding, load balancing, and the list goes on... That takes exponentially more number of people and time and mainly risk.

It works for Figma(for now), but for it to work as a solution for other companies with different hardware, data schema and access patterns will add even more complexity to the mix.

It's a excellent solution but I don't think it be good enough in the long run.

[hobs]

And that would be the solution you'd absolutely abhor. Database sharding has a bunch of gotchas and things to think about because you must consider query access patterns along with your sharding (unless you want the devs to get owned or have very weird behavior.)

Building something super simple can be ok for the base use case but if you are a multi-billion dollar company you can probably afford a few dbas to actually make your platform good.

[robust-cactus]

Complexity is a great reason to implement something like this in-house. It's probably better to understand (and fully control) the sharding and transaction mechanism than to trust a third party with such a core piece of infra.

As companies get larger they move further up the stack whether it's sharding techniques, databases, custom orchestration software, their own networking hardware, etc.