Une seule table a atteint plusieurs milliards de lignes et les écritures ralentissent. Quelles sont vos options ?

Épuisez d'abord les options les moins chères : de meilleurs index, l'archivage des lignes froides, le déplacement des grosses colonnes ailleurs, et des réplicas de lecture pour la charge de lecture. Ensuite partitionnez la table, en général par temps ou par tenant, pour que chaque partition reste petite et que les anciennes puissent être supprimées instantanément. Le sharding entre bases séparées vient en dernier, parce qu'il vous coûte les requêtes inter-shards, les transactions distribuées et le rééquilibrage, et que le choix de la clé de shard est très difficile à changer ensuite.

D'abord je chercherais ce qui est réellement lent, parce qu'une grosse table n'est pas automatiquement un problème. En général c'est la maintenance des index à chaque insertion, ou quelques index inutilisés, ou l'autovacuum qui prend du retard. Je commence donc par les gains faciles : supprimer les index que personne n'utilise, déplacer une grosse colonne texte ou JSON dans une table annexe pour que les lignes principales restent compactes, et archiver tout ce qui dépasse la politique de rétention. Si c'est encore vraiment trop gros, je partitionne, normalement par temps pour des données de type événement, ce qui garde chaque partition petite, permet au planificateur d'élaguer jusqu'à la plage pertinente, et transforme la suppression des données de l'an dernier en suppression d'une partition plutôt qu'en delete qui tourne une journée. Le sharding est le dernier recours parce qu'il change le modèle de programmation : les jointures inter-shards disparaissent, les transactions deviennent distribuées, et le rééquilibrage devient un projet. Si je shard, la clé fait l'objet d'une vraie réflexion, puisque sharder une table d'événements par identifiant client vous donne un shard chaud dès qu'un client est dix fois plus gros que les autres.