PgDog - una herramienta para hacer sharding de Postgres sin extensiones adicionales

• Un transaction pooler y gestor de replicación lógica para PostgreSQL desarrollado en Rust, que ofrece escalado horizontal y automatización de sharding
• Permite hacer sharding fácilmente en bases de datos PostgreSQL sin extensiones, optimizado para administrar cientos de bases de datos y cientos de miles de conexiones
• Como balanceador de carga de BD que opera en la capa de aplicación (OSI 7), puede enrutar automáticamente SELECT a réplicas y el resto a la primaria
• Al igual que PgBouncer, soporta pooling de transacciones/sesiones, pero además parsea consultas para enrutar automáticamente a shards e incluso fusiona resultados
• Usando COPY y replicación lógica, puede distribuir datos automáticamente entre shards o aplicar sharding a una BD existente sin tiempo de inactividad
• La configuración puede definirse fácilmente con archivos TOML y admite reconfiguración en tiempo de ejecución
• A diferencia de Citus, que usa extensiones de Postgres, es un proxy externo a la BD, por lo que también puede usarse en RDS, Cloud SQL, etc.

---

Introducción del proyecto y valor principal

• PgDog es una solución open source para bases de datos PostgreSQL que soporta sharding sencillo, replicación lógica, transaction pooling, balanceo de carga L7 y, en general, escalado horizontal integral
• Está desarrollado en Rust, lo que le permite ofrecer alto rendimiento y seguridad
• Sin necesidad de instalar extensiones, PgDog hace posible sharding, distribución de datos, recuperación ante fallos y balanceo de carga flexible con solo desplegar un proxy único
• A diferencia de productos competidores (por ejemplo, PgBouncer, PgCat, etc.), su fortaleza está en que soporta tanto sharding automático como replicación lógica, además de cambios de configuración en operación y monitoreo en tiempo real

Funciones principales

Balanceo de carga (Load Balancer)

• PgDog es un proxy a nivel de aplicación de la capa 7 de OSI que distribuye consultas entre múltiples réplicas y nodos primarios de PostgreSQL para prevenir fallas y sobrecarga
• Ofrece varias estrategias de distribución, como round robin, aleatoria y mínimo número de conexiones
• Identifica el tipo de consulta y enruta automáticamente SELECT a las réplicas, mientras que las demás consultas de escritura se envían al nodo primario
• Realiza health checks y failover automático cuando ocurre una falla, garantizando disponibilidad incluso ante errores de red o fallas de hardware

Transaction pooling

• Al igual que PgBouncer, PgDog soporta pooling de transacciones y sesiones para gestionar eficientemente los recursos de conexión, permitiendo atender cientos de miles de clientes con unas pocas conexiones backend

Sharding

• Parsea directamente la sintaxis de las consultas para extraer la clave de sharding y aplicar el algoritmo de enrutamiento óptimo
• También soporta consultas cross-shard entre bases de datos de múltiples shards, integrando los resultados en memoria y entregándolos de forma transparente al cliente
• Al ejecutar el comando COPY, soporta distribución de datos a múltiples shards mediante parsing de CSV, lo que resulta conveniente para cargas masivas
• Basado en el protocolo de replicación lógica de PostgreSQL, permite sincronización en segundo plano sin interrupciones y agregar o expandir shards en tiempo real durante la operación

Monitoreo

• Soporta tanto una base de datos de administración al estilo PgBouncer como un endpoint OpenMetrics
• Proporciona ejemplos de monitoreo externo y dashboards para Datadog y otros servicios

Configuración y tiempo de ejecución

• Entornos principales: Kubernetes (con chart de Helm), Docker y entorno local (compilación con Rust), lo que facilita el despliegue y las pruebas
• Normalmente basta con escribir 2 archivos de configuración (pgdog.toml, users.toml) para completar una configuración mínima de sharding y operación basada en usuarios
• La mayoría de los valores de configuración pueden modificarse en tiempo real y aplicarse dinámicamente sin reiniciar el proceso

Rendimiento y licencia

• PgDog es un proxy de red asíncrono de alto rendimiento basado en Rust y Tokio, enfocado en minimizar el movimiento de datos y contener la degradación del rendimiento
• Los resultados de benchmarks se ofrecen en la documentación oficial para poder establecer referencias de rendimiento
• Está publicado bajo la licencia open source AGPL v3, totalmente abierta para uso interno empresarial y personalización privada
• Sin embargo, las empresas que ofrezcan servicios en nube pública deben compartir los cambios realizados al código

Estado del proyecto y contribuciones

• Actualmente se encuentra en una etapa temprana, por lo que se recomienda su adopción por parte de early adopters; la estabilidad por función sigue mejorando con actualizaciones continuas
• Las pruebas por funcionalidad y los benchmarks también continúan de forma constante
• Se agradecen las contribuciones de la comunidad open source; para más detalles, consulta las Contribution Guidelines

Conclusión

• PgDog ofrece una excelente solución para equipos de desarrollo y empresas que necesitan escalabilidad horizontal, alta disponibilidad y sharding automático de PostgreSQL en entornos de producción
• Su gran ventaja es que puede aplicarse rápidamente y personalizarse sin necesidad de extensiones adicionales ni infraestructura compleja

[GN⁺]

Opiniones en Hacker News

• Saluda a Lev y explica que actualmente está comparando PgDog con una solución construida internamente para sharding de una base de datos Postgres de 40 TB, menciona que necesita algo que funcione como Vitess for PostgreSQL, y enfatiza que además de scatter-gather hacen falta administración de configuración basada en algo como etcd, división de shards y transacciones best-effort para aplicar cambios de esquema en todos los shards, pregunta por la experiencia de reescritura de consultas con pg_query.rs, comparte que ha sentido dificultades por la inmutabilidad de los tipos AST y la falta de deep clone, y comenta que al final está usando el crate sqlparser con soporte para el patrón Visitor, además de desarrollar como side project cambios de esquema online para PG basados en shadow tables y replicación lógica

  • Dice que le alegra la propuesta de colaboración y comparte su contacto, explica que la administración de configuración ya puede resolverse con K8s o varias herramientas de CD y que es posible sincronizar la recarga de configuración de PgDog, menciona que los cambios de esquema en todos los shards con transacciones best-effort ya funcionan, que lo ideal son cambios de esquema idempotentes pero que también están considerando two-phase commit en caso de fallas, pone como ejemplo que la división de shards puede hacerse con replicación lógica y menciona su experiencia con más de 10 TB en Instacart, comparte el procedimiento de abrir un replication slot, restaurar a N instancias, borrar los datos cuyo número de shard no coincide y volver a sincronizar con replicación lógica, comenta una idea de división paralela usando la replicación lógica de Pg 17 sobre una streaming replica, y también que está considerando copiar datos directamente con COPY hacia tablas externas, señala que pg_query.rs ahora parece funcionar de forma mutable y que últimamente lo está usando activamente para reescritura y generación de consultas, subrayando como ventaja importante que está basado 100% en el parser de Postgres, y que la funcionalidad de "deparse" en varias partes abre la puerta a trabajos complejos

• Pregunta si, si existiera un Vitess para Postgres, Yugabyte no estaría cumpliendo ya ese papel

• Dice que, aunque al ver solo las funciones clave parezca pequeño, considera que la capacidad de usar PgDog para sacar lógica del código y separar lecturas a réplicas de lectura y escrituras al primario es una ventaja enorme, comenta que muchas apps no soportan separación R/W directamente, así que manejarlo a nivel de proxy le dio grandes mejoras de velocidad en el pasado, y felicita el proyecto

  • Le responden que esa función ya puede usarse también en pgcat y comparten el enlace de pgcat

  • Comparte que en Instacart hacían separación R/W con Makara, pero que resultaba bastante tedioso implementar lo mismo una y otra vez en distintos entornos de lenguaje como Python o Go

• Comenta que el proyecto le parece impresionante, pero que siente cierta distancia frente al sharding completamente automatizado, explica que normalmente el sharding se hace en los límites de tenancy y que quiere que exista fricción al cruzar esos límites, opina que los joins entre shards son distintos de los joins dentro de un shard en rendimiento, memoria y CPU, por lo que le gustaría que eso quedara claramente expuesto, aunque aclara que no duda del proyecto en sí y que ve muchísimos casos de uso

  • Pregunta por qué querría fricción a propósito, y añade que los problemas de rendimiento de los joins entre shards en general se entienden bien y pueden seguirse con métricas en tiempo real, que al final se necesitan ambos enfoques y que la alternativa de hacer joins en el código de la app no es especialmente deseable

• Comenta que viene siguiendo de cerca a PgDog y que le parece muy impresionante, felicita el lanzamiento y expresa que espera que siga evolucionando

  • Responde que un viaje de 15 años apenas está comenzando

• Opina que el principal atractivo es que maneja consultas distribuidas manteniendo transparencia y compatibilidad en la capa de red, considera naturales las limitaciones actuales de la documentación y espera que hagan falta trade-offs, dice que le intriga cómo lo resolverán y propone sumarse a la conversación si hay más discusiones

  • Le invitan a unirse a la comunidad en Discord y comparten el enlace de invitación

• Menciona que la mayor dificultad en una solución como PgDog es manejar correctamente hasta el último 1% de las consultas complejas sobre shards, o detectar consultas anómalas, así como garantizar por completo el aislamiento y la consistencia

• Dice que lo primero que revisó al ver la documentación fue si soportaba Unique Index, pero lamenta que todavía no lo haga porque requiere reescritura de consultas y un motor de ejecución separado, aunque aun así ve potencial y tiene expectativas

  • Responden que, como pequeña compensación, ya soporta generar primary keys únicas en todos los shards y comparten la documentación relacionada, y comentan que implementar unique indexes cross-shard es costoso porque obliga a verificar todas las consultas, dejando abierta la idea

• Enfatiza que es el proyecto de Postgres más interesante que ha visto en años, y opina que los benchmarks publicados parecen cubrir solo connection pooling básico, por lo que le da curiosidad qué pasa cuando entran en juego el parseo de consultas o los joins entre shards

  • Explican que el parser de consultas se cachea, por lo que al usar prepared statements o placeholders casi no hay costo más allá de locks y búsquedas en hash, y que en el caso de joins entre shards el costo puede subir cuando los filtros no son óptimos, además de que podría ser necesario paginar a disco si el conjunto de resultados es grande, estiman que por ahora se están enfocando primero en OLTP para empujar al máximo los joins hacia abajo, y prevén que pronto crecerá también la demanda por joins entre shards

• Lo califica como una innovación muy necesaria para la escalabilidad de Postgres y felicita el lanzamiento

• Dice que el proyecto se ve excelente y felicita el lanzamiento

  • Responde subrayando que es el resultado de años de esfuerzo