- PgDog es un proxy que se coloca delante de PostgreSQL y permite escalar Postgres horizontalmente mediante pooling de conexiones, balanceo de carga y sharding, sin reescribir la aplicación
- Considera que la razón por la que existen bases de datos como Mongo o Dynamo es el problema de escalabilidad de Postgres, y que si pudiera manejar tablas de más de 100 TB y 1 millón de consultas por segundo, no harían falta otras bases de datos
- PgDog procesa más de 2 millones de consultas por segundo en producción, ha fragmentado más de 20 TB dentro del rango verificado y supera 1.4 millones de Docker pulls en GitHub
- El equipo de tres personas ha abordado problemas de sharding de Postgres en RDS, Aurora y EC2, basándose en su experiencia con aplicaciones grandes sobre Postgres y en la expansión 5x de Instacart en abril de 2020
- Recaudó 5.5 millones de dólares de Basis Set, YC, Pioneer Fund y otros, y está construyendo PgDog como un producto open source para hacer que Postgres funcione a cualquier escala
Financiamiento y dirección del producto
- El desarrollo de Postgres comenzó desde la idea de que es la única base de datos necesaria
- Considera que la razón por la que existen bases de datos como Mongo o Dynamo es el problema de escalabilidad de Postgres
- Cree que si Postgres pudiera manejar correctamente tablas de más de 100 TB y 1 millón de consultas por segundo, no usarían otras bases de datos
- PgDog hace posible el escalado horizontal colocando un proxy delante del Postgres existente
- PgDog puede desplegarse en cualquier lugar, incluido on-premise y la cuenta cloud del usuario
- Basta con descargar la imagen de Docker y cambiar
DATABASE_URLpara que PgDog se encargue del trabajo
Estado actual y contexto de ejecución
-
Estado actual
- PgDog procesa más de 2 millones de consultas por segundo en decenas de despliegues de producción
- Dentro del rango verificado, PgDog ha hecho sharding de más de 20 TB
- PgDog es open source y cualquiera puede desplegarlo
- Superó 1.4 millones de Docker pulls en GitHub
- Sale una nueva versión todos los jueves
- La comunidad de Discord sigue creciendo, con preguntas respondidas y soporte todos los días
-
El equipo y por qué confiar
- PgDog es una startup pequeña de tres personas
- El equipo está formado por un ingeniero de infraestructura, un ingeniero de aplicaciones y un generalista
- El equipo creó aplicaciones sobre Postgres y las hizo funcionar a gran escala desde antes de que Postgres recibiera tanta atención
- Ganó experiencia operando Postgres en Instacart durante abril de 2020, cuando la empresa se expandió 5x
- En ese momento, el mayor problema era lograr que Postgres procesara cientos de miles de pedidos de entrega de supermercado por minuto
- Hicieron sharding de Postgres en RDS, Aurora y EC2, y resolvieron problemas reales con principios básicos y mucho código
- Esa misma tecnología ahora se ofrece como producto open source
-
Forma de despliegue y financiamiento
- El desarrollo de PgDog no fue un pivote; escalar Postgres sigue siendo el único objetivo
- PgDog está hecho para ejecutarse en el cloud del usuario, en racks de colocation, on-premise o en una laptop
- PgDog funciona donde se necesite, sin dependencias ni costos serverless ocultos
- Si puedes darle CPU, el código multihilo de PgDog usará todos los CPU
- Cree que la adopción de Postgres seguirá creciendo
- Recaudó 5.5 millones de dólares de Basis Set, YC, Pioneer Fund y otros inversionistas, asegurando varios años de runway
- El objetivo es hacer que Postgres funcione correctamente para todos y a cualquier escala
-
Enterprise edition
- La Enterprise edition de PgDog está en desarrollo para facilitar su ejecución en AWS
- La Enterprise edition ofrece soporte del equipo basado en SLA
1 comentarios
Comentarios de Hacker News
Se dice que la razón de que existan bases de datos como Mongo o Dynamo son los problemas de escalado de Postgres, pero después de usar Postgres en varios lugares, el problema número uno siempre fue la alta disponibilidad, no el escalado
Con un solo clúster de Postgres procesábamos fácilmente 100 mil transacciones por minuto, pero si el nodo principal moría, te llamaban, hacías un failover manual al nodo de reserva y luego también había que reemplazar manualmente ese nodo de reserva
Las herramientas manuales eran muy delicadas, pero al menos funcionaban; las soluciones automatizadas ni se acercaban
Como faltaba una buena historia de HA, terminamos evitando Postgres autogestionado siempre que era posible
Un balanceador con health checks y failover viene funcionando por defecto, y ahora ya está lo bastante probado en producción como para que valga la pena revisarlo
https://github.com/patroni/patroni
En mi caso de uso funcionó realmente bien
Si en “Why Us” escribes “Operamos Postgres en Instacart, y cuando la empresa creció 5x en abril de 2020, el mayor problema fue lograr que Postgres procesara cientos de miles de pedidos de entrega de supermercado por minuto”, no creo que haya una mejor respuesta para por qué nosotros que esa
Parece que una sola instancia de Postgres podría manejarlo sin problema
Los SSD empresariales modernos y de buena calidad pueden manejar alrededor de 35 mil
fsyncreales por segundoClaro, no sé si eso era por Postgres o por otros defectos de diseño
Básicamente quiero entenderlo, pero ahora mismo tengo una DB de 4 TB en un solo servidor grande
Si uso una herramienta proxy como PGDog, ¿la idea sería levantar 8 servidores pequeños que se encarguen de unos 500 GB cada uno, más 1 servidor intermedio de tamaño medio para el proxy?
El proyecto actual tiene muchísimo tráfico de escritura desde varios servicios, y la web lee desde ahí
Ya nos estamos acercando al punto en que ni la indexación, ni la optimización de consultas, ni el caché, ni las mejoras de servidor ayudan más
También estamos viendo mover la mayor parte de los datos estáticos a ClickHouse para reducir el tamaño de la DB, pero me gustaría saber si PgDog u otro tipo de sharding serviría para este caso de uso
Estaría bueno que nos contactaras (lev@pgdog.dev)
Podemos ayudarte o al menos decirte qué está funcionando y qué no en este momento, para que tengas claro cuáles son tus opciones
Si lees la documentación de pgdog, verás que tienes que indicarle cómo enrutar las solicitudes al servidor shard correspondiente; no funciona mágicamente por sí solo
Aun así, tiene valor porque reutiliza conexiones que en Postgres son especialmente costosas
Como no es magia, necesitas entender qué está pasando por dentro y, por ejemplo, no hay transacciones entre shards
El sharding es difícil si te importa la consistencia de los datos, así que primero vería si la aplicación puede beneficiarse de réplicas de lectura
Cada réplica tiene una copia completa de todos los datos y las escrituras solo van al master; tú mismo tienes que decidir qué transacciones está bien ejecutar en una réplica que puede ir un poco atrasada respecto al tiempo casi real
Por ejemplo, las lecturas para construir una página web suelen ser seguras en una réplica, pero una operación de leer-modificar-escribir no lo es
Me pregunto cómo ayuda esto con las actualizaciones de versión mayor, que son la mayor causa de tiempo de inactividad en Postgres
Pooler es excelente para failover y balanceo de carga, pero por las actualizaciones seguimos necesitando de forma regular entre 10 y 20 minutos de downtime una o dos veces al año
La replicación lógica de la versión vieja a la nueva puede ayudar, pero aun así parece que hay que moverlo todo al clúster nuevo sin escrituras parciales ni estados raros
Me pregunto si alguien tiene experiencia con esto
La base de datos es de alrededor de 1 a 1.5 TB, pero el volumen de cambios o la cantidad de consultas por segundo no es enorme
Básicamente es el método que describen aquí: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
Si tienes infraestructura como código, creas un clúster nuevo con la misma configuración y solo la versión mayor distinta, importas el esquema, empiezas a copiar los datos desde una réplica de lectura de la versión vieja, dejas de aceptar escrituras en la versión vieja (empieza el downtime), sincronizas los números de secuencia y apuntas el servicio al clúster nuevo (termina el downtime)
Si usas algo como CloudNativePG, parte de este proceso se automatiza con herramientas CLI y sintaxis declarativa
Si no, te toca dedicar tiempo a entenderlo por tu cuenta
Puede sonar complejo, pero después de practicarlo en una base de datos de staging, si sale bien puedes aplicar el mismo procedimiento en producción
Además, parece que Postgres 19 trae un parche para replicación lógica única de secuencias: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
Si haces girar los clústeres de forma secuencial, el downtime es muy pequeño, algo así como 60 segundos
A estas alturas ya dudo que llegue a verla algún día
Todavía me pregunto por qué esto no se considera prioridad absoluta
Felicidades por la ronda, Lev
Aquí estamos usando PgDog con buenos resultados
Me gusta bastante una de sus funciones de proxy: manejar configuraciones de conexión distintas por conexión, por ejemplo
statement_timeoutCuando investigué RDS Proxy antes, no lo soportaba, y creo que con pgbouncer pasaba lo mismo, así que habría requerido muchos cambios en la aplicación
En PgDog simplemente funciona de forma transparente
Me pregunto si es comparable con multigres de Supabase, que acaban de anunciar
Veo una Enterprise Edition; me gustaría saber con claridad qué funciones no son open source
También me pregunto si esperan que las funciones nuevas que agreguen queden bajo licencia EE para compensar a los inversionistas de VC
La primera es el control plane que administra despliegues multinodo, para ofrecer una experiencia “lista para usar” que haga fácil desplegar y usar PgDog
La segunda es calidad de servicio (QoS), que bloquea automáticamente consultas problemáticas para que no tumben la base de datos
Por último, también puedes obtener soporte con SLA garantizado hasta P0
Las funciones nuevas se dividen en dos categorías
El sharding y operar Postgres a gran escala siempre será open source; la administración de infraestructura y las funciones que facilitan operar PgDog a gran escala serán enterprise
Está bueno ver que aparezcan PgDog, Neki y multigres
Con razón este es el problema central de Postgres, y también que no tenga index hints; por eso tengo ganas de ver Postgres 19
Configurarlo es difícil, pero hoy en día con ayuda de AI se volvió más fácil
pg_hint_planno está en el core, pero es bastante capaz cuando necesitas sobreescribir el planner“Hemos shardeado más de 20 TB, de lo que sabemos” probablemente sea un error de redacción
20 TB no es tanto
Supongo que han shardeado bastante más que eso
La proporción entre datos calientes y fríos cambia según la base de datos, así que sin más información no se puede comparar
Una mejor métrica podría ser IOPS
RDS tiene un IOPS máximo bastante bajo a menos que gastes mucho más en IOPS provisionadas o uses Aurora
Como referencia, hace casi 10 años en Segment operábamos una sola instancia de Aurora PostgreSQL con unos 50 TB de datos, y se usaba para indexar datos de posibles identificadores dentro de un corpus de archivos mucho más grande almacenado en S3
PgDog está bueno
La verdad no lo necesito, pero un día, caminando por el bosque, no tenía nada que escuchar y me topé por casualidad con el podcast Postgres FM; me interesó y ahora lo uso en mi Kubernetes on-premises
https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb