PlanetScale explica en un artículo técnico cómo escalar una base de datos relacional más allá de unos pocos terabytes mediante particionado (sharding), una técnica que distribuye los datos y las consultas entre múltiples servidores. El texto parte de una arquitectura clásica con un servidor de aplicaciones conectado a una base de datos Postgres o MySQL y describe por qué las soluciones verticales (más CPU y RAM) y las réplicas de lectura resultan insuficientes: las escrituras siguen limitadas al servidor principal, las réplicas no aumentan la capacidad de almacenamiento y las copias de seguridad de bases de datos monolíticas pueden tardar horas o incluso días.
A continuación, el artículo introduce el particionado como respuesta a estos cuellos de botella. Con dos terabytes de datos, por ejemplo, se pueden usar cuatro particiones de 500 GB cada una; para almacenar un petabyte se necesitarían 256 particiones, cada una con un servidor principal y dos réplicas, lo que suma 768 servidores. Para que las aplicaciones vean esa infraestructura compleja como una única base de datos coherente, interviene una capa de intermediarios (proxy o enrutador) que se encarga de decidir qué datos van a cada servidor, qué consultas se dirigen a cada partición, cómo se ejecutan las consultas que abarcan varias particiones, cómo se realizan las copias de seguridad y cómo se gestiona la respuesta ante fallos. PlanetScale menciona herramientas como Neki para Postgres y Vitess para MySQL como implementaciones concretas de esta capa de enrutamiento, y señala que PgBouncer cumple un papel similar, aunque más sencillo, en bases de datos sin particionar.