Neki fragmenta PostgreSQL sin interrumpir el servicio
PlanetScale ha lanzado Neki, una plataforma de PostgreSQL fragmentado ("sharded") que permite escalar la popular base de datos de código abierto más allá de los límites de una sola máquina sin sacrificar la continuidad del servicio. La compañía presentó el producto en fase de "platform preview", con la promesa de alcanzar cientos de millones de consultas por segundo y volúmenes de datos del orden de petabytes por base de datos, todo ello operando sobre instancias reales de Postgres.
El anuncio llega tras año y medio de la incursión de PlanetScale en el ecosistema Postgres. Según la propia empresa, en ese periodo han incorporado a varios miles de clientes, algunos de ellos con tamaños comparables a los mayores despliegues de MySQL que la compañía gestiona desde hace ocho años. La motivación fue una observación recurrente: los equipos que crecían con Postgres terminaban topándose con el techo de una sola máquina, y ni siquiera el uso de hardware metálico de gran tamaño podía posponer indefinidamente ese límite. PlanetScale asegura que, hasta la llegada de Neki, no existía una alternativa satisfactoria para esos clientes.
El problema es bien conocido por los administradores de bases de datos: tablas demasiado grandes para vacuum o indexación sin afectar al tráfico, copias de seguridad que se prolongan durante horas, límites de conexiones, ventanas de mantenimiento para cambios de esquema y riesgo de wraparound de transacciones. La fuente corporativa reconoce que las soluciones existentes implican renunciar a algo: el particionado a nivel de aplicación obliga a introducir lógica de enrutamiento en el código, mientras que las bases de datos distribuidas "compatibles" con Postgres ocultan la clave de fragmentación, eliminan extensiones y añaden complejidad y latencia difíciles de depurar.
Neki se construye sobre un principio declarado: "apegarse a Postgres, no trabajar alrededor de él, simularlo ni alejarse de él". La arquitectura se compone de cuatro elementos diferenciados. En primer lugar, los routers de Neki, que hablan el protocolo de cable nativo de Postgres, de modo que los drivers y ORMs existentes siguen funcionando con una única cadena de conexión. Cada router incorpora un parser completo de consultas Postgres, un planificador distribuido y sistemas de buffering, y es capaz de escalar vertical y horizontalmente para evitar convertirse en un cuello de botella.
En segundo lugar, los shards y los shard groups: cada shard es una instancia real de Postgres con una primaria y al menos dos réplicas distribuidas entre zonas de disponibilidad, sin motor de almacenamiento modificado. Las extensiones, el soporte SQL y el rendimiento se comportan como en Postgres porque, de hecho, lo son. Los shards se organizan en grupos que permiten ubicar diferentes tablas o cargas de trabajo en conjuntos distintos, cada uno con un perfil de configuración que define tamaño de instancia, número de réplicas, almacenamiento, parámetros y extensiones.
El tercer pilar es el connection pooling mediante sidecars que se ejecutan junto a cada instancia de Postgres. La fuente destaca que Neki controla ambos extremos de la conexión, lo que permite dimensionar los pools según lo que cada instancia puede servir realmente, en lugar de estimarlo desde fuera del proceso como haría un PgBouncer tradicional.
Finalmente, el control plano se encarga de monitorizar la salud de cada nodo, gestionar conmutaciones planificadas y no planificadas, y coordinar los flujos de trabajo de re-sharding, cambios de esquema y actualizaciones de versión. Toda la topología de datos se define mediante un archivo JSON que asigna las tablas lógicas a shards físicos, especificando índices de shard (la columna de enrutamiento y el método de hash) y grupos de shard (cuántos shards abarca un conjunto de tablas y cuáles son).
Una de las prestaciones diferenciales es que las operaciones que tradicionalmente requerían ventanas de mantenimiento —cambios de esquema, actualizaciones de versión, conmutaciones por fallo, importaciones y re-sharding— se ejecutan como flujos de trabajo integrados que aprovisionan nodos destino, los sincronizan mediante replicación, conmutan el tráfico mediante una metafunción de Neki y retiran los nodos antiguos, todo a través de la misma conexión psql que utiliza la aplicación.
La fuente de Neki en neki.dev incide en la capacidad de fragmentar shards saturados a medida que crecen las cargas, creando shards destino, poniéndolos al día con replicación y moviendo el tráfico mediante cambios de topología. También destaca la posibilidad de ejecutar cada shard como un clúster de Postgres de alta disponibilidad entre zonas de disponibilidad, de forma que los fallos queden aislados en la unidad más pequeña posible, así como la realización de escrituras distribuidas en una sola transacción, coordinada de modo atómico.
En cuanto al posicionamiento de mercado, Neki llega con la etiqueta de "platform preview", lo que significa que PlanetScale desaconseja ejecutar cargas de producción en esta fase, dado que el producto aún está cambiando y algunas modificaciones serán incompatibles. No obstante, los usuarios pueden empezar con un solo shard e ir fragmentando a medida que crezcan, o importar una base de datos existente con una migración de tiempo de cero. También es posible ejecutar Neki sin fragmentar, como una única primaria con réplicas, para beneficiarse desde el primer momento de las mejoras en pooling de conexiones, DDL en línea, actualizaciones sin tiempo de inactividad y monitorización de salud.
PlanetScale sostiene que Neki incorpora además todas las funcionalidades que los usuarios conocen de su plataforma principal, como Insights, recomendaciones de esquema, branching y MCP. A juzgar por las cifras que обещает la compañía —más de 100 millones de consultas por segundo y más de un petabyte por base de datos con cero tiempo de inactividad en re-sharding— el producto apunta a los entornos de misión crítica (los llamados tier 0) donde unos segundos de caída pueden convertirse en un incidente público. La pregunta ahora es si la comunidad de Postgres adoptará una solución de fragmentación que, según sus creadores, no obliga a renunciar a la compatibilidad, las extensiones ni la familiaridad del motor original.