PlanetScale lanza Neki: Postgres shardado sin tocar tu app

Qué es Neki y por qué PlanetScale lo construye ahora

Neki es el nuevo servicio de PlanetScale para correr Postgres shardado, disponible desde este momento en platform preview. La compañía detrás de Vitess —el proyecto de sharding de MySQL que nació en YouTube y se graduó en la CNCF en febrero de 2018— decidió aplicar la misma lógica a Postgres después de ver a sus clientes chocar repetidamente contra el techo de una sola máquina.

El contexto importa: PlanetScale lleva ocho años operando algunos de los clústeres MySQL shardados más grandes del mundo, con cargas de miles de millones de consultas por segundo donde un minuto de inactividad se convierte en un incidente público. Cuando lanzaron PlanetScale Postgres hace aproximadamente un año y medio, miles de equipos se sumaron, y la conclusión fue incómoda: escalar verticalmente comprando más CPU y más IOPS no resuelve los problemas estructurales de Postgres a gran escala —el vacuum, los índices, los backups, el wraparound de transacciones, los límites de conexiones y las ventanas de mantenimiento no escalan de forma lineal con el hardware.

Cómo está armado Neki por dentro

Neki sigue un principio explícito: Postgres real, no Postgres "compatible". Cada shard es una instancia auténtica de Postgres, con 1 primary y al menos 2 réplicas distribuidas entre zonas de disponibilidad. No hay un motor de almacenamiento modificado ni SQL recortado: las extensiones y el comportamiento son los del propio Postgres, porque lo que corre es Postgres.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El sistema se compone de cuatro piezas que se reparten el trabajo:

Router. Tu aplicación se conecta al router con un único connection string. Habla el protocolo wire de Postgres, así que los drivers y ORMs existentes siguen funcionando sin cambios. El router parsea la consulta con un parser completo de Postgres, construye un plan distribuido que decide qué shards la ejecutan, reparte el trabajo y une los resultados en un único stream. Escala vertical y horizontalmente para que ninguno se convierta en cuello de botella.
Shards reales. Cada shard es Postgres puro, con su configuración por shard group: tamaño de instancia, número de réplicas, almacenamiento, parámetros y extensiones. Esto permite dimensionar cada grupo de shards según su carga real, no con un único molde para todos.
Sidecars. Corren al lado de cada instancia Postgres. Es la pieza que hace que el pool de conexiones de Neki sea sensiblemente mejor que poner un PgBouncer delante: como Neki controla ambos extremos de la conexión (router y Postgres), puede dimensionar los pools a lo que cada instancia realmente sirve, en lugar de estimarlo desde fuera del proceso.
Control plane. Supervisa la salud de cada nodo, ejecuta switchovers planificados y failovers no planificados, y coordina los workflows de resharding, cambios de esquema y upgrades de versión.

Toda la configuración vive en la data topology, un JSON que mapea tus tablas lógicas sobre shards físicos. Ahí defines los shard indexes (la columna por la que Neki enruta y cómo se hashea su valor) y los shard groups (qué tablas viven sobre qué conjunto de shards). Los routers cachean la topología y la consultan en cada plan.

Qué cambia respecto a las opciones que ya conocías

Cuando una base Postgres se queda grande, las salidas históricas obligan a ceder algo. Neki se posiciona explícitamente frente a tres de ellas:

Subir de instancia. Funciona un tiempo. Pero llega un punto en que no existen máquinas más grandes, y los problemas no escalan de forma lineal con más cores e IOPS.
Sharding a nivel de aplicación. Reparte bien, pero empuja el routing al código de tu app, lo que se vuelve caro de mantener y debuggear a medida que el sistema crece.
Bases Postgres "compatibles" distribuidas. Ocultan la shard key, retiran extensiones, añaden latencia y complejidad, y dificultan el debugging.

La apuesta de Neki es mantener Postgres intacto y poner la inteligencia en el router y el control plane. Los workflows que normalmente requieren una ventana de mantenimiento —cambios de esquema, upgrades de versión, failovers planificados y no planificados, imports y resharding— se ejecutan como workflows online desde la misma conexión psql que usa tu aplicación. Provisionan los nodos destino, los ponen al día con replicación, conmutan el tráfico con una metafunción __neki y retiran los nodos viejos, sin cortar el servicio.

Además, Neki conserva las funcionalidades que ya son seña de PlanetScale: Insights, recomendaciones de esquema, branching, integración MCP, entre otras. Y se puede arrancar sin shardear: un solo primary con réplicas, con pool mejorado, DDL online, upgrades sin downtime y health monitoring. Cuando toca shardear, el resharding es un workflow contra el clúster que ya tienes.

Qué significa esto para tu startup

Si tu producto corre sobre Postgres y todavía no te topaste con el techo de una sola máquina, esta noticia probablemente no cambia tu semana. Si ya lo estás sufriendo, es una opción a evaluar con cuidado, porque ataca exactamente ese dolor: shards reales con extensiones, sin reescribir tu ORM ni aprender una API nueva.

Tres acciones concretas para founders:

Mide hoy el techo de tu Postgres. Mira tamaño de tablas, tiempos de vacuum, latencia de backups, picos de conexiones y si tu equipo ya está programando ventanas de mantenimiento. Esos números son los que justifican mirar Neki o cualquier alternativa de sharding.
Evalúa Neki en preview, no en producción. El propio equipo de PlanetScale lo dice: durante el platform preview el producto sigue cambiando y algunos cambios serán breaking. Úsalo para probar arquitectura y workloads, no para servir tráfico real a tus usuarios.
No asumas que "Postgres compatible" es Postgres. Antes de migrar a CockroachDB, Yugabyte u otra Postgres-compatible distribuida, valida qué extensiones pierdes, qué SQL se comporta distinto y cómo debuggearás latencia multi-shard. La promesa de Neki es justamente evitar esa trampa.

El contexto de PlanetScale

PlanetScale se fundó como empresa comercial sobre Vitess, el proyecto open source nacido en YouTube en 2010 y aceptado en la CNCF en febrero de 2018, según reportó TechTarget. En junio de 2021 cerró una Serie B de US$30M liderada por Insight Partners con participación de Andreessen Horowitz y SignalFire, llevando el total levantado hasta ese anuncio a US$55M, con Jiten Vaidya como CEO y cofundador. Neki es la apuesta para llevar esa misma receta —escala horizontal sin sacrificar el motor— al mundo Postgres, donde la presión por sharding masivo es creciente.