PgDog YC P25: $5.5M seed y buscan Founding Engineer

PgDog levanta $5.5M para escalar PostgreSQL sin tocar tu código

PgDog, la startup de infraestructura para bases de datos del batch YC P25, acaba de cerrar una ronda seed de $5.5 millones liderada por Basis Set Ventures con participación de Pioneer Fund y Y Combinator. La compañía busca ahora un Founding Software Engineer para expandir su equipo mientras decenas de empresas ya usan su proxy en producción.

Si tu startup depende de PostgreSQL y estás viendo límites de escalabilidad, esto te interesa: PgDog promete escalar horizontalmente tu base de datos sin reescribir una línea de código ni instalar extensiones.

¿Qué hace exactamente PgDog?

PgDog es un proxy open source escrito en Rust que se sitúa entre tu aplicación y PostgreSQL. Su función principal es resolver el talón de Aquiles de Postgres: el escalado horizontal.

🚀 Antes de buscar capital, valida el negocio

Una comunidad de emprendedores construyendo con IA como apalancamiento — sin humo de startup, con foco en lo que funciona.

👥 Construir en la comunidad

A diferencia de soluciones tradicionales como PgBouncer (que solo hace connection pooling) o RDS Proxy (solución propietaria de AWS), PgDog combina múltiples capacidades en una sola capa:

Connection pooling: reduce la sobrecarga de conexiones simultáneas
Load balancing: distribuye consultas entre múltiples instancias de Postgres
Sharding horizontal automático: divide tus datos entre shards sin que tu app lo note
Cross-shard queries: ejecuta consultas que atraviesan múltiples shards y agrega resultados

Lo diferencial es que no requiere cambios en el código de la aplicación ni en el schema de la base de datos. Funciona como drop-in replacement para entornos como AWS RDS, Aurora, Cloud SQL, Supabase y Neon.

El fundador y la trayectoria técnica

Lev Kokotov fundó PgDog en 2025 con una tesis clara: PostgreSQL domina como base de datos generalista, pero el escalado horizontal sigue siendo doloroso. Antes de PgDog, Kokotov ya había creado PgCat, otro proyecto de pooling para Postgres, lo que le dio experiencia profunda en los límites arquitectónicos del ecosistema.

La decisión de escribir PgDog en Rust no es casual. Rust se ha convertido en el lenguaje preferido para infraestructura de alto rendimiento y baja latencia, combinando seguridad de memoria con concurrencia eficiente. Para un proxy que debe enrutar miles de consultas por segundo con latencia mínima, Rust ofrece ventajas técnicas decisivas sobre alternativas en C++ o Go.

¿Por qué $5.5M en seed para infraestructura de bases de datos?

El mercado de database infrastructure está en expansión constante. Cada startup que escala enfrenta eventualmente el mismo problema: Postgres funciona perfecto hasta que no funciona. En ese punto, las opciones tradicionales son dolorosas:

Escalar verticalmente (más CPU/RAM) → costos exponenciales
Migrar a bases distribuidas (CockroachDB, Cassandra) → reescritura masiva
Implementar sharding manual → complejidad operativa brutal

PgDog ataca el tercer problema con una capa de abstracción que hace transparente el sharding. La validación del mercado viene de dos fuentes: decenas de empresas ya lo usan en producción y los inversores de infraestructura más sofisticados (Basis Set Ventures tiene tesis específica en developer tools e infra) apostaron en la ronda seed.

El rol de Founding Software Engineer: qué implica realmente

La búsqueda de un Founding Software Engineer no es una contratación típica. Este rol implica:

Diseño de infraestructura distribuida: arquitectura de sharding, replicación lógica, consistencia
Optimización de consultas en Rust: parsing de SQL, routing inteligente, agregación cross-shard
Trabajo en open source: PgDog es open source, lo que significa visibilidad pública del código y comunidad
Compensación competitiva: $150-225k anuales + 1-3% de equity, con opción de trabajo remoto (preferencia por SF, California u Oregon)

Los requisitos son específicos: 3+ años de experiencia, dominio de Rust y PostgreSQL, y ciudadanía o visa estadounidense. No es un rol para juniors: están buscando alguien que pueda tomar decisiones arquitectónicas desde el día uno.

Competencia y posicionamiento en el ecosistema

PgDog no compite directamente con Neon, Supabase o Aurora (managed Postgres), sino que se posiciona como capa complementaria. De hecho, su documentación afirma compatibilidad con estos servicios.

La competencia real está en dos frentes:

Categoría	Competidores	Diferencial de PgDog
Connection pooling	PgBouncer, RDS Proxy	Sharding integrado + routing SQL-aware
Sharding para Postgres	Citus (extension), soluciones custom	Sin extensiones, sin cambios de app

El riesgo competitivo existe: Citus (adquirido por Microsoft) tiene años de madurez en sharding para Postgres, pero requiere extensión y cambios de schema. PgDog apuesta por la transparencia total como ventaja.

¿Qué significa esto para tu startup?

Si estás construyendo sobre PostgreSQL y proyectas escalar, hay tres lecciones accionables de este caso:

1. Evalúa tu estrategia de escalado antes de necesitarla

No esperes a que Postgres colapse bajo carga. Si tu startup está en crecimiento y ves señales de límites (latencia creciente en consultas, costos de RDS escalando verticalmente), investiga opciones de sharding antes de la crisis. PgDog y alternativas similares permiten planificar escalado horizontal con menos dolor que una migración de última hora.

Acción concreta: Audita tus consultas más pesadas y identifica qué tablas podrían shardearse por clave natural (userid, tenantid, región geográfica). Documenta esto como parte de tu roadmap técnico.

2. Considera el trade-off open source vs. proprietary

PgDog es open source, lo que tiene implicaciones para tu stack:

Ventaja: transparencia total, posibilidad de self-host, comunidad que reporta bugs
Riesgo: menos soporte empresarial que una solución managed, responsabilidad operativa en ti

Para startups early-stage, el open source puede ser ventajoso (costos bajos, flexibilidad). Para empresas en escala, evalúa si necesitas SLA y soporte 24/7 que solo vendors comerciales ofrecen.

Acción concreta: Si estás evaluando PgDog o similar, prueba en staging con tráfico real. Mide latencia agregada por el proxy vs. conexión directa. El overhead debe ser <5% para ser viable en producción.

3. El batch YC P25 como señal de validación

Estar en YC P25 (batch de primavera/verano 2025) no garantiza éxito, pero sí indica que el proyecto pasó filtro de due diligence técnico y de mercado. Para founders evaluando herramientas de infraestructura, los batches de YC funcionan como señal de calidad mínima: los inversores ya validaron que el problema es real y la solución es técnicamente sólida.

Acción concreta: Cuando evalúes developer tools, verifica si tienen backing de inversores especializados en infra (Basis Set, a16z infra, Sequoia Scout). No es garantía, pero reduce riesgo de que el proyecto desaparezca en 12 meses.

Tendencias más amplias en infraestructura de datos

El caso de PgDog refleja tres tendencias del mercado 2025-2026:

Postgres para casi todo: La comunidad sigue extendiendo Postgres antes que migrar a bases especializadas. Herramientas como PgDog permiten mantener Postgres como single source of truth incluso a escala.
Rust en infraestructura crítica: Más proxies, poolers y sistemas de replicación se escriben en Rust por seguridad de memoria y rendimiento. Si eres engineer, aprender Rust tiene ROI creciente en roles de infra.
Simplificación de stack: Startups prefieren capas que resuelvan múltiples problemas (pooling + sharding + routing) en vez de componer 4-5 herramientas distintas. PgDog compite por ser esa capa unificada.

Conclusión

PgDog representa una apuesta técnica ambiciosa: hacer que PostgreSQL escale horizontalmente con la misma facilidad con que escala verticalmente. Los $5.5M en seed, el respaldo de YC P25 y la adopción temprana en producción son señales positivas, pero el verdadero test será la madurez del producto en los próximos 18-24 meses.

Para founders y CTOs: si PostgreSQL es crítico para tu negocio, vale la pena monitorear este espacio. La capa de infraestructura entre tu app y la base de datos está evolucionando rápido, y las decisiones que tomes hoy sobre escalado definirán tus opciones técnicas dentro de dos años.