Shard a Live Database Without Downtime/Playground
Sharding Postgres while it is running
Click a part to change it, put something in front of it, or kill it. Turn the traffic up. Every number moves as you go; nothing is graded. Traffic is not in the brief; these rates are assumed to show one primary running out of room.
- Requests failing
- 0%
- Backlog growing
- none
- Instances running
- 48
What goes through it
| Operation | Offered | Outcome | Wait | Up |
|---|---|---|---|---|
| App reads | 40k/s | All served | 148 ms | 99.999% |
| App writes | 8,000/s | All served | 159 ms | 99.999% |
| Unmigrated writes | 3,000/s | All served | 116 ms | 99.95% |
| Change logbackground | 11k/s | Keeping up | – | – |
| Backfill copiesbackground | 2,000/s | Keeping up | – | – |
Wait is the expected time a caller waits; Up is the share of time every part it waits on is running.
What your changes did
Nothing yet. This is the reference design: change something to see what it buys and costs.
At this traffic
Risk:
Unmigrated writes stop if its one instance does. Kill it to see.
ReplicationNotion: The Great Re-shard: adding Postgres capacity (again) with zero downtime ↗
Ask AI what your design does
AIThe numbers above come from a simple model. The AI reads your design, what you changed and these numbers, and explains where it holds and where it fails, citing how the engineers who built it did it. It can be wrong.