Principles of Sharding for Relational Databases

I find the &quot;you don&#x27;t want to shard&quot; camp quite annoying. Of course, I don&#x27;t want to shard! Who does?! It adds complexity, both implementation-wise and operational.<p>But if you got 5 TB of data, that needs to be in a SSD drive, then please tell me how I can get that into 1 single physical database.

Hey everyone, it&#x27;s Ozgun. When I first wrote this blog post, it was much longer. Based on initial feedback, I edited out parts of it to keep the post focused.<p>If you have any questions that aren&#x27;t covered in the post, happy to answer them here!

Interesting that sharding by customer for a sass business is the example of the best use of sharding. That can also go very wrong - what if you get a huge customer that&#x27;s as big as everyone else combined? You&#x27;re effectively maxed out at 2 shards.<p>Definitely depends on the workload, but often the &quot;micro service&quot; approach (whether or not it&#x27;s a true micro service in its own runtime) of sharding just one type of data&#x2F;small set of related tables that you can shard by a primary key or user id or something seems like the only reasonable option for sharding. If your data is becoming unwieldy there&#x27;s often a bottleneck data set that&#x27;s bigger than everything else so you don&#x27;t necessarily have to share everything all at once.

I laugh every time I read that word.

She shard on a turtle!