Una sola tabla ha crecido hasta varios miles de millones de filas y las escrituras se están ralentizando. ¿Qué opciones tienes?

Agota primero las opciones baratas: mejores índices, archivar filas frías, sacar las columnas grandes y réplicas de lectura para la carga de lectura. Después particiona la tabla, normalmente por tiempo o por inquilino, para que cada partición siga siendo pequeña y las antiguas se puedan eliminar al instante. El sharding entre bases de datos separadas va el último, porque te cuesta consultas entre shards, transacciones distribuidas y rebalanceo, y la elección de clave de shard es muy difícil de cambiar después.

Primero averiguaría qué está lento de verdad, porque una tabla grande no es automáticamente un problema. Normalmente es el mantenimiento de índices en cada insert, o unos cuantos índices que nadie usa, o el autovacuum quedándose atrás. Así que empiezo por lo barato: quitar los índices que nadie usa, mover una columna grande de texto o JSON a una tabla lateral para que las filas principales sigan siendo compactas, y archivar todo lo anterior a la política de retención. Si de verdad sigue siendo demasiado grande, particiono, normalmente por tiempo si son datos tipo evento, lo que mantiene cada partición pequeña, permite al planificador podar hasta el rango relevante y convierte borrar los datos del año pasado en eliminar una partición en lugar de un delete que corre un día entero. El sharding es el último recurso porque cambia el modelo de programación: los joins entre shards desaparecen, las transacciones pasan a ser distribuidas y el rebalanceo es un proyecto. Si hago sharding, la clave se piensa de verdad, porque hacer sharding de una tabla de eventos por id de cliente te da un shard caliente en cuanto un cliente es diez veces mayor que el resto.