Postgres escala: 1.875 writes/seg para tu startup

¿Cuánto puede escalar realmente PostgreSQL en 2026?

Un solo servidor PostgreSQL 18 puede sostener hasta 1.875 escrituras transaccionales por segundo en configuración realista, equivalente a 162 millones de writes por día. Este dato proviene de benchmarks realizados en hardware de gama alta (16 núcleos Ryzen 9, NVMe top-tier y 64 GB RAM), con latencia promedio de 9.2 ms (P50: 3.1 ms, P99: 58 ms).

Para founders tech que evalúan infraestructura, esto significa que la mayoría de startups nunca alcanzará este límite. Un banco mediano o una startup con alto volumen de transacciones puede operar cómodamente en un solo nodo de Postgres sin necesidad de arquitecturas complejas.

Sin embargo, los benchmarks inflados que circulan en internet (50k writes/sec) omiten un detalle crítico: synchronous_commit=on, configuración predeterminada para garantizar durabilidad, impide esos números. Las escrituras en PostgreSQL, incluyendo WAL (Write-Ahead Logging), son síncronas. El I/O asíncrono solo aplica a lecturas, donde sí se observa mejora de 2-3x en storage cloud.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Cómo se compara PostgreSQL con MySQL en 2026?

Los datos de 2026 son contundentes: PostgreSQL supera a MySQL en rendimiento de escritura con 4.9x más velocidad en inserts y 3.5x menor latencia de escritura. Esta ventaja se debe a mejoras implementadas en PostgreSQL 17, como VACUUM incremental y ejecución paralela optimizada.

El impacto financiero es medible: startups que migraron de MySQL a PostgreSQL 17 reportaron ahorros de $4.800/mes en costos de infraestructura y reducción del 94% en tiempo de queries. No es solo rendimiento técnico; es rentabilidad operativa.

La adopción refleja esta tendencia. Según la encuesta de Stack Overflow 2025, el 55.6% de developers prefiere PostgreSQL, marcando la primera vez que supera a MySQL (40.5%). Para founders que deciden stack tecnológico, esto no es solo moda: es validación de comunidad y ecosistema.

¿Cuáles son los límites reales de concurrencia en Postgres?

El cuello de botella principal en alta concurrencia no es la base de datos en sí, sino la configuración de durabilidad. Con synchronous_commit=on (recomendado para producción), PostgreSQL prioriza consistencia sobre throughput máximo. Esto es correcto para workflows durables donde perder una transacción no es opción.

Los límites prácticos que debes monitorear como founder:

Throughput máximo sostenible: ~1.875 tps en nodo único con hardware moderno
Latencia P99 aceptable: <50 ms para la mayoría de casos de uso
Punto de migración: >10k workflows concurrentes o latencia sostenida >50ms P99

Las escrituras en background (logs, actualizaciones de estado de workflows) aumentan la carga total, no la reducen. Muchos equipos cometen el error de asumir que operaciones asíncronas liberan la base de datos, pero en PostgreSQL cada write genera WAL y debe ser confirmado.

¿Qué estrategias existen para escalar PostgreSQL más allá de un nodo?

Cuando tu startup supera los límites de un nodo único, tienes tres caminos probados en producción:

1. Particionado de tablas
Effective para tablas grandes en sistemas de workflows. Mantiene rendimiento y gestionabilidad sin cambiar arquitectura. TimescaleDB, extensión de PostgreSQL especializada en series temporales, ofrece 1.000x más velocidad con particionado automático, compresión y agregados continuos. Ideal para eventos de workflows, IoT o sistemas de tracking.

2. Sharding horizontal
PostgreSQL no tiene sharding nativo, pero extensiones como Citus o proveedores managed como Supabase y Neon lo habilitan. Estas plataformas soportan 40+ extensiones y permiten escalado horizontal transparente. Para founders que priorizan velocidad de desarrollo sobre control total, esta es la ruta más rápida.

3. Extensiones especializadas
Para workflows con IA: pgvector maneja hasta 500K vectores con 2.800 QPS, y pgvectorscale escala a >10M vectores para casos RAG. pg_cron permite jobs SQL internos (limpieza, reportes), reduciendo dependencia de orquestadores externos. La tendencia 2025-2026 es usar PostgreSQL como hub único eliminando silos de datos.

¿Qué alternativas existen cuando Postgres no es suficiente?

Para workflows durables masivos (>10k concurrentes), plataformas especializadas superan a PostgreSQL puro:

Temporal / Cadence: Ejecución durable escalable, open source. Ideal cuando necesitas guarantees de ejecución exact-once y manejo nativo de retries, timeouts y continuación de workflows.
n8n: Open source, enfocado en backend workflows. Gratis en self-hosted o cloud por uso. Recomendado para equipos técnicos de data/ops.
Make: Integración visual, ~$9/mes. Adecuado para pymes operativas que priorizan velocidad sobre control.
Zapier: Automatización simple, ~$20/mes. Para equipos no técnicos o validación temprana.

El artículo original de DBOS.dev benchmarking workflow execution en PostgreSQL concluye que, aunque Postgres escala bien para casos medianos, soluciones dedicadas son necesarias para ejecución workflow extrema. No es falla de PostgreSQL; es trade-off entre generalidad y especialización.

¿Qué significa esto para tu startup?

Si estás construyendo un producto con workflows durables, aquí tienes el marco de decisión basado en datos reales:

Quédate con PostgreSQL si:

Tu volumen es <1.875 tps (162M writes/día)
Latencia P99 está <50 ms consistentemente
Usas extensiones (TimescaleDB, pgvector, pg_cron) para casos específicos
Priorizas costos bajos y versatilidad sobre optimización extrema

Considera migrar si:

Superas 10k workflows concurrentes de forma sostenida
Latencia P99 excede 50ms a pesar de optimización
Writes en background representan >30% de carga total
Necesitas guarantees de ejecución que PostgreSQL no ofrece nativamente

Dos acciones concretas para implementar esta semana:

Instrumenta monitoreo de latencia P99 en tus queries críticas de workflows. No promedios, no P50. P99 te muestra la experiencia del peor caso, que es lo que importa para retención de usuarios. Si P99 >50ms, empieza a investigar cuellos de botella antes de escalar hardware.
Evalúa extensiones antes de migrar. Antes de saltar a Temporal o arquitecturas complejas, prueba TimescaleDB para series temporales o pg_cron para jobs programados. Muchas startups descubren que una extensión resuelve el problema sin costo de migración. Proveedores como Supabase y Neon ya incluyen 40+ extensiones pre-configuradas.

La lección de founders que han estado en las trincheras: inicia con PostgreSQL. Es barato, versátil y la mayoría nunca alcanzará sus límites. Migra solo cuando los datos (no las suposiciones) te digan que es necesario. El costo de sobre-ingeniería temprana mata más startups que los límites de base de datos.