A single table has grown to several billion rows and writes are slowing down. What are your options?

Exhaust the cheaper options first: better indexes, archiving cold rows, moving large columns out, and read replicas for read load. Then partition the table, usually by time or tenant, so each partition stays small and old partitions can be dropped instantly. Sharding across separate databases comes last, because it costs you cross shard queries, distributed transactions and rebalancing, and the shard key choice is very hard to change later.

First I would find out what is actually slow, because a big table is not automatically a problem. Usually it is index maintenance on every insert, or a few unused indexes, or autovacuum falling behind. So I start with the cheap wins: drop indexes nothing uses, move a large text or JSON column into a side table so the main rows stay compact, and archive anything older than the retention policy. If it is genuinely still too big, I partition, normally by time for event style data, which keeps each partition small, lets the planner prune to the relevant range, and turns deleting last year's data into dropping a partition rather than a delete that runs for a day. Sharding is the last resort because it changes the programming model: cross shard joins go away, transactions become distributed, and rebalancing is a project. If I do shard, the key gets real thought, since sharding an events table by customer id gives you a hot shard the moment one customer is ten times bigger than the rest.