Citus: escalar Postgres horizontalmente sin dejarlo
Actualizado: 2026-07-07
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 enero de 2019[1] y durante los tres años siguientes se mantuvo esa doble edición. El giro llegó con el lanzamiento de Citus 11.0 en junio de 2022[2], cuando dejó de existir una versión empresarial separada: funciones que antes eran de pago, como el rebalanceo de shards sin bloqueos o el soporte multiusuario con propagación de roles, pasaron a la extensión abierta. El motor sigue bajo la licencia AGPLv3 que ya usaba desde sus primeros lanzamientos[3], pero ahora cubre el producto entero.
Esto es relevante porque Citus ya no es un producto con funciones bloqueadas tras un muro de pago. Es una extensión de Postgres que puedes instalar con apt, compilar desde fuentes o desplegar en cualquier distribución sin licencias adicionales. La serie 13.x, publicada desde 2025, añade soporte para Postgres 17[4], lo que significa que puedes combinar las mejoras recientes del motor base, incluida la reescritura de la gestión de memoria de VACUUM[5], con el particionado distribuido sin renunciar a ninguna de las dos, incluidas las mejoras de planificación de consultas que repasamos en Postgres 17: skip scan y otras mejoras.
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. La propia documentación de Citus[6] describe paneles con tiempos de respuesta por debajo del segundo que se mantienen aunque el volumen de datos siga creciendo, algo que un único nodo no sostiene sin este reparto.
-
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:
-
Tu aplicación ya corre en Postgres.
-
Ha crecido hasta necesitar más de un servidor.
-
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.
Este artículo también está disponible en inglés.
