Vertical Sharding Sucks

Summary

Vertical sharding sucks Apr 11th, 2025Lev Kokotov Vertical sharding, sometimes called functional sharding, takes tables out of your main database and puts them somewhere else. Most of the time, it’s another Postgres database. This reduces load on the main DB and gives your app some breathing room to grow. This also breaks your app into pieces and makes your backend engineers sad. Sad engineers blow up your product roadmap and your hopes of building stuff. A bit of theory A bit of a strong start, I agree. If you haven’t had your morning coffee yet, I’d go get one now and come back. Tables (apps) are never really split up. Even in the perfect world, two apps developed by the same company will need to talk to each other. Sure, that can be done over HTTP, but that doesn’t change the fact that one app is effectively dependent on the other. So while the databases are sharded, the apps are not. Adding more containers to your Kubernetes cluster adds more 9’s to your SLA. Adding more databases does the opposite. It’s a bit counterintuitive, but here’s why: containers are independent but databases are not. So, if your app needs both DBs to fulfill a request, both DBs have to be working. Uptime formula Calculating your uptime is done by taking 100% and subtracting probabilities of failure for each component in your system. If you have a database in RDS, it guarantees that it will work 99.95% of the time. So, if you have one DB, your app’s SLA (in a perfect world) is: 100% - (100% - 99.95%) = 99.95% That was a weird way to remove 0.05 from a 100, but here is why. When calculating uptime of two independent systems, the probability of failure for both is multiplied. So if you have two completely separate databases, and your app can use one or the other (think replicas), your SLA is the probability of both of them failing at the same time: 100% - ((100% - 99.95%) × (100 - 99.95%)) = 99.9975% This is why adding replicas to your database (or containers to your Kube cluster) gives yo...