PlanetScale lanza Neki, su motor de sharding nativo para PostgreSQL

PlanetScale ha publicado Neki, su producto de base de datos distribuida para PostgreSQL. El servicio entra en fase de preview en la plataforma y permite escalar cargas de trabajo más allá del límite de un único servidor físico. Quien despliega la solución mantiene una sola cadena de conexión y el comportamiento estándar de Postgres en cada fragmento. Se trata de un intento directo de resolver el techo de rendimiento y escalabilidad que muchos equipos encuentran al crecer con esta base de datos relacional. La compañía construye esta herramienta gracias a la experiencia acumulada en ocho años administrando grandes clústers de MySQL para clientes con millones de consultas por segundo. Han llevado esta misma lógica a PostgreSQL, donde observaron que los usuarios top llegaban al límite de lo que un solo host puede ofrecer. El metal ayudaba a ganar tiempo, pero no resolvía la ecuación a largo plazo. Hasta ahora, las opciones eran limitadas. Aplicar sharding a nivel de aplicación exige reescribir la lógica de negocio para controlar el encaminamiento. Las bases de datos alternativas "compatibles con Postgres" suelen ocultar la clave de fragmentación, eliminar la compatibilidad con extensiones y añadir latencia difícil de depurar. Neki apuesta por no desviarse del estándar. Cada shard es un clúster de Postgres real, con un nodo primario y al menos dos réplicas distribuidas en tres zonas de disponibilidad. No hay un motor de almacenamiento modificado. Las extensiones, el soporte de SQL y el rendimiento se comportan exactamente como en el producto original. La conexión se gestiona a través de enrutadores que hablan el protocolo de red estándar de Postgres. Los drivers y objetos relacionales de mapeo (ORM) actuales funcionan sin cambios. El enrutador incluye un planificador de consultas distribuido que decide en qué fragmentos ejecutar la carga y combina los resultados. Puede escalar tanto vertical como horizontalmente para evitar cuellos de botella. La configuración se maneja mediante una topología de datos en formato JSON. El administrador define la clave de shard, los índices y cómo agrupar las tablas para separar cargas de trabajo distintas. Los sidecars integrados gestionan el pooling de conexiones de forma que ajustan los recursos a lo que la instancia de Postgres puede realmente servir, mejorando la gestión frente a herramientas externas como PgBouncer. El plano de control supervisa la salud de los nodos y automatiza tareas operativas que antes requerían ventanas de mantenimiento. Incluye migraciones de esquema, actualizaciones de versión, importación de datos y resharding en caliente. "Todos estos procesos corren como flujos de trabajo integrados", indica la compañía. Incluso se puede operar sin fragmentar al inicio. El servicio funciona como un primario con réplicas estándar, ofreciendo las mejoras en pooling y operaciones online. Cuando llegue el momento de escalar, el resharding se ejecuta como una operación más sobre el clúster existente. La versión actual es una ventana previa a la producción, lo que implica que los entornos críticos requieren precaución. El enfoque de eliminar capas de abstracción propietaria en favor de un Postgres puro fragmentado representa un cambio de chip respecto a otras ofertas del mercado de bases de datos gestionadas.