Citus: escalar Postgres horizontalmente sin dejarlo

Actualizado: 2026-05-03

Postgres es una base de datos magnífica hasta que dejas de caber en un solo nodo. En ese momento se abren tres caminos: mover todo a una base distribuida como CockroachDB o YugabyteDB, montar una arquitectura de fragmentos manuales con herramientas externas, o usar Citus. Los tres son válidos según el contexto, pero los tres implican decisiones muy distintas. Este post se centra en Citus porque en 2025 ha terminado de encontrar su sitio: ya no es una apuesta arriesgada ni una promesa comercial, sino una extensión de Postgres sólida que resuelve un problema concreto con menos disrupción que las alternativas.

Puntos clave

• Citus añade una extensión al coordinador y a los nodos trabajadores que intercepta la planificación de consultas y las distribuye, manteniendo desde fuera la apariencia de un único Postgres.
• La clave de distribución es la decisión más importante que tomarás: condiciona el rendimiento de todas las consultas posteriores.
• Citus brilla en tres escenarios: multi-tenant con particionado limpio por cliente, analítica en tiempo real sobre series temporales, y aplicaciones que han crecido dentro de Postgres hasta necesitar el siguiente salto sin reescribir.
• Las consultas que cruzan claves de distribución diferentes son lentas porque el coordinador tiene que mover datos entre trabajadores.
• Citus funciona mejor cuando se adopta como decisión arquitectónica temprana, no como parche tardío.

La historia corta: de fork comercial a extensión abierta

Citus nació en 2011 como una startup que ofrecía un Postgres distribuido. Durante años funcionó como una mezcla de código abierto y edición comercial con funciones avanzadas solo en la versión empresarial. Microsoft compró la empresa en 2019 y durante dos años el proyecto se enfrió visiblemente: la comunidad temía que terminara como un producto cerrado de Azure. El giro llegó en 2022, cuando Microsoft abrió la totalidad del código, incluidas las funciones empresariales históricas, bajo licencia AGPLv3.

Esto es relevante porque Citus ya no es un producto con telemetría dudosa y bloqueo de funciones. Es una extensión de Postgres que puedes instalar con apt, compilar desde fuentes o desplegar en cualquier distribución sin pagar licencias. La versión actual 13.x es compatible con Postgres 17, lo que significa que puedes combinar las mejoras recientes del motor base con el particionado distribuido sin renuncias.

Cómo funciona el modelo de Citus

La idea central es diseñada con Postgres en mente desde el primer día. En lugar de reescribir el motor de almacenamiento, añade una extensión al coordinador y a los nodos trabajadores que intercepta la planificación de consultas y las distribuye. Desde fuera el cluster se parece a un único Postgres; te conectas al coordinador por el puerto habitual y lanzas SQL estándar.

Citus distingue tres tipos de tabla:

• Tablas distribuidas: se particionan por una columna llamada clave de distribución, que define en qué trabajador vive cada fila.
• Tablas de referencia: se replican en todos los nodos porque son pequeñas y se consultan cruzadas con las distribuidas.
• Tablas locales: permanecen solo en el coordinador para datos que no necesitan escalar.

La clave de distribución ideal cumple dos condiciones. Primero, reparte datos de forma razonablemente uniforme entre trabajadores para evitar puntos calientes. Segundo, es la columna que aparece en la mayoría de filtros y uniones, porque eso permite al coordinador dirigir la consulta a un único trabajador en lugar de dispersarla por todo el cluster.

Los casos de éxito más claros son aplicaciones multi-tenant donde el identificador de cliente es la clave natural: cada inquilino vive en un trabajador, las consultas del panel de un cliente solo tocan un nodo, y el cluster entero sirve a muchos inquilinos en paralelo.

Dónde encaja bien y dónde duele

Citus brilla en tres escenarios concretos:

• Multi-tenant: donde los datos particionan limpiamente por cliente u organización. La eficiencia es casi lineal: el cluster crece añadiendo trabajadores y la latencia por consulta apenas cambia.
• Analítica en tiempo real sobre datos tipo series temporales: Citus reparte las consultas agregadas en paralelo entre trabajadores y las consolida en el coordinador. En estas cargas se han visto factores de mejora de diez a veinte veces frente a un Postgres monolítico con el mismo hardware total.
• Aplicaciones que han crecido dentro de Postgres hasta llegar a un nodo grande y necesitan el siguiente salto sin reescribir. Migrar a CockroachDB o Spanner implica cambios significativos en el modelo de datos, el SQL, las transacciones y la operación. Migrar a Citus es mucho más incremental.

Donde duele es igualmente importante:

• Las consultas que cruzan claves de distribución diferentes son lentas porque el coordinador tiene que mover datos entre trabajadores. Si tu carga tiene muchas consultas ad-hoc que no respetan el modelo de distribución, Citus da peor rendimiento que un Postgres monolítico bien ajustado.
• El soporte de transacciones multi-partición existe, pero es más lento y frágil que las transacciones locales en un solo Postgres.
• La operación de un cluster Citus es más compleja que un Postgres único: tiene un coordinador que es punto único de fallo salvo que montes alta disponibilidad con Patroni o similar.

Citus frente a las alternativas distribuidas

La respuesta corta al comparar con CockroachDB o YugabyteDB: Citus gana cuando tu carga particiona limpiamente y quieres seguir en Postgres; las otras ganan cuando necesitas transacciones distribuidas sin fricción sobre cualquier acceso.

CockroachDB y YugabyteDB son bases distribuidas por diseño desde el primer día. Implementan consenso Raft en cada rango de datos, ofrecen transacciones ACID globales sin limitaciones topológicas. A cambio, la latencia mínima de una transacción es mayor que en Postgres, el SQL compatible cubre el 95 por ciento pero no todo, y el ecosistema de extensiones es más pobre.

Citus, en cambio, es un atajo inteligente. Acepta que la mayoría de aplicaciones con problemas de escala tienen un particionado natural claro, y si lo respetas, te permite escalar horizontalmente sin salir de Postgres.

Cuándo compensa

Citus compensa cuando se dan tres señales a la vez:

1. Tu aplicación ya corre en Postgres.
2. Ha crecido hasta necesitar más de un servidor.
3. Tiene un particionado natural claro por cliente, región, proyecto o similar.

Si las tres señales están presentes, Citus ofrece el camino de menor disrupción y un rendimiento excelente en su rango. Si falta la tercera, estás perdiendo el tiempo: elegirás mal la clave de distribución y Citus dará resultados peores que un nodo monolítico más grande.

La segunda lectura es que Citus funciona mejor cuando se adopta como decisión arquitectónica temprana, no como parche tardío. Los proyectos que planificaron el modelo de datos con Citus en mente desde el principio escalaron suavemente. Los que llegaron con un Postgres denso tras años de evolución orgánica tuvieron que reestructurar esquemas, mover datos y reescribir consultas antes de ver beneficios.

Si el sistema ya tiene problemas de rendimiento hoy, mejor estabilizar el nodo único primero con replicación para lectura y cachés, y plantear Citus como próxima fase. Este mismo razonamiento aplica al debate SQLite en producción: la herramienta correcta depende del perfil de carga, no de lo que está de moda.

Conclusión

Citus es la respuesta correcta para un nicho específico: Postgres que ha crecido más de lo que aguanta un nodo y cuya carga tiene particionado natural. Fuera de ese nicho, las alternativas distribuidas o el scale-up son mejores opciones. Dentro de él, Citus ofrece un camino de menor disrupción que cualquier alternativa.