Postgres Queues: 30K ejecuciones/seg sin Redis en 2026

Postgres alcanza 30.000 ejecuciones por segundo en colas de trabajo sin Redis

Un equipo de ingeniería demostró que PostgreSQL puede manejar hasta 30.000 ejecuciones de colas por segundo en un solo servidor, desafiando la creencia establecida de que se necesitan sistemas externos como Redis o RabbitMQ para colas de trabajo de alta demanda. Este hallazgo tiene implicaciones directas para CTOs y founders que buscan simplificar su infraestructura sin sacrificar rendimiento.

La clave no está en cambiar de base de datos, sino en aplicar tres técnicas específicas: SKIP LOCKED para eliminar contención, ajustes en niveles de aislamiento de transacciones e índices parciales selectivos. Para una startup que ya usa Postgres como base de datos principal, esto significa reducir complejidad operacional y costos de infraestructura manteniendo consistencia transaccional completa.

¿Por qué Postgres como sistema de colas funciona en 2026?

Durante años, el consenso en ingeniería fue claro: Postgres para datos transaccionales, Redis o RabbitMQ para colas de trabajo. Esta separación tenía sentido cuando Postgres mostraba limitaciones en patrones de acceso concurrente a filas específicas. Sin embargo, benchmarks recientes de 2025-2026 revelan un panorama diferente.

👥 ¿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

Según investigaciones técnicas publicadas, un solo servidor PostgreSQL 18 puede sostener 144.000 escrituras por segundo o procesar 43.000 workflows por segundo en configuraciones optimizadas. En términos de colas de trabajo específicamente, se reportan hasta 12.100 queued workflows por segundo de forma sostenida. Estos números compiten directamente con sistemas especializados cuando el diseño es correcto.

La ventaja fundamental de usar Postgres como queue system es la consistencia transaccional. Cuando un job se encola como parte de una transacción de negocio (por ejemplo, crear un usuario y encolar un email de bienvenida), garantizas atomicidad sin necesidad de patrones complejos de saga o compensación. Para startups en etapa de crecimiento, esta simplificación arquitectónica reduce puntos de falla y deuda técnica.

Las 3 técnicas que permiten escalar colas en Postgres

SKIP LOCKED: elimina la contención entre workers

El patrón tradicional de colas en bases de datos usaba SELECT ... FOR UPDATE, lo que causaba que múltiples workers esperaran por las mismas filas, generando cuellos de botella severos. SKIP LOCKED cambia completamente este comportamiento: cuando un worker selecciona jobs pendientes, las filas ya bloqueadas por otros workers se omiten automáticamente en lugar de esperar.

La consulta típica se ve así:

SELECT id
FROM jobs
WHERE status = 'pending'
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 1;

Este patrón permite que múltiples workers consuman jobs en paralelo sin bloquearse entre sí. Cada worker toma el siguiente job disponible y lo procesa de forma independiente. La reducción de contención es dramática: en lugar de tener 10 workers esperando por la misma fila, todos trabajan en jobs diferentes simultáneamente.

Índices parciales: optimiza solo lo que necesitas

El error más común al implementar colas en Postgres es indexar toda la tabla de jobs. La mayoría de las operaciones de cola solo necesitan acceder a jobs pendientes, no a los completados o fallidos. Un índice parcial sobre el subconjunto activo reduce drásticamente el tamaño del índice y mejora el rendimiento.

Ejemplo de índice parcial optimizado:

CREATE INDEX CONCURRENTLY idx_jobs_pending_priority
ON jobs (priority DESC, run_at, id)
WHERE status = 'pending';

Este diseño ofrece tres ventajas concretas: primero, el índice es mucho más pequeño porque solo cubre jobs activos. Segundo, el query planner de Postgres usa este índice de forma más eficiente para búsquedas de jobs pendientes. Tercero, el costo de mantenimiento (autovacuum, actualizaciones) se reduce significativamente porque el índice no incluye filas históricas.

Benchmarks reproducibles de 2026 muestran que configuraciones con índices parciales bien diseñados alcanzan 28.668 TPS con latencia media de 8.9 ms y P99 de 11.7 ms en cargas de trabajo de ~100 GB. Sin índices parciales, la latencia se dispara y el throughput cae drásticamente bajo carga concurrente.

Ajuste de niveles de aislamiento de transacciones

El nivel de aislamiento por defecto en Postgres es READ COMMITTED, suficiente para la mayoría de los casos de uso de colas. Sin embargo, en escenarios de altísima concurrencia, ajustar este parámetro puede reducir overhead. La clave es mantener transacciones cortas y atómicas: reclamar el job, procesarlo y actualizar el estado dentro de una transacción mínima.

Transacciones largas retienen locks por más tiempo, aumentando la probabilidad de contención incluso con SKIP LOCKED. El patrón recomendado es: seleccionar y claimar el job en una transacción, procesar fuera de la transacción, y actualizar el estado en una segunda transacción breve.

Postgres vs Redis vs RabbitMQ: cuándo usar cada uno

La pregunta correcta no es "¿cuál es mejor?" sino "¿cuál encaja con mi caso de uso?". Cada sistema tiene ventajas específicas:

PostgreSQL es ideal cuando:

Tu aplicación ya usa Postgres como base de datos principal
Necesitas consistencia transaccional entre datos de negocio y cola
El volumen de jobs es moderado a alto (hasta decenas de miles por segundo)
Quieres minimizar infraestructura y puntos de falla
Los jobs tienen duración significativa (segundos o minutos)

Redis tiene ventaja cuando:

Necesitas latencia sub-milisegundo consistente
Tu workload son jobs muy pequeños y de altísima frecuencia (cientos de miles por segundo)
La persistencia no es crítica o usas Redis con AOF/RDB
Requieres estructuras de datos especializadas (streams, sorted sets)
Tu cola es más volátil que durable

RabbitMQ es preferible cuando:

Necesitas routing complejo de mensajes (exchanges, bindings)
Requieres semánticas de entrega avanzadas (ack, requeue, dead letter)
Tu arquitectura es orientada a eventos con múltiples consumidores
La separación entre base de datos y mensajería es un requisito arquitectónico

Herramientas como Oban (Elixir) y pgqueue demuestran que el ecosistema de jobs persistentes sobre PostgreSQL está maduro para producción. Oban, en particular, es usado por startups y empresas establecidas que procesan millones de jobs diarios sobre Postgres sin problemas de escalabilidad.

Benchmarks de PostgreSQL 18 muestran mejoras de 38% en throughput frente a versiones anteriores en patrones de escritura concurrente, alcanzando ~58.000 TPS con 32 workers. Esto indica que la brecha entre Postgres y sistemas especializados se está cerrando rápidamente.

¿Qué significa esto para tu startup?

Si eres CTO o founder técnico, esta información te permite tomar decisiones de infraestructura más informadas en 2026:

Acción 1: Evalúa tu stack actual antes de agregar complejidad

Antes de implementar Redis o RabbitMQ solo para colas, analiza si tu volumen actual justifica la complejidad adicional. Si tu aplicación ya usa Postgres y procesas menos de 10.000 jobs por segundo, implementar SKIP LOCKED e índices parciales puede ser suficiente. Esto reduce costos operacionales, simplifica debugging y mantiene consistencia transaccional.

Implementa un POC con la siguiente estructura:

Tabla jobs con columnas: id, status, priority, runat, payload, createdat
Índice parcial sobre WHERE status = 'pending' ORDER BY priority DESC, run_at
Workers que usen SELECT ... FOR UPDATE SKIP LOCKED
Monitoreo de latencia P99 y throughput

Acción 2: Define umbrales claros para escalar horizontalmente

Establece métricas objetivas que disparen la migración a un sistema especializado:

Latencia P99 consistentemente por encima de 50 ms en operaciones de cola
Throughput sostenido por encima de 50.000 jobs por segundo
Contención de locks que no se resuelve con optimización de índices
Requisitos de mensajería que Postgres no puede satisfacer (fanout masivo, routing complejo)

Hasta alcanzar esos umbrales, Postgres bien configurado es suficiente y más simple de operar.

Acción 3: Invierte en mantenimiento preventivo

Las colas en Postgres requieren mantenimiento activo para evitar bloat. Implementa:

Archivado o particionado de jobs completados (mover a tabla histórica semanalmente)
Autovacuum agresivo en la tabla de jobs
Monitoreo del tamaño de la tabla y índices
Limpieza de jobs fallidos o expirados

Un patrón efectivo es particionar la tabla de jobs por mes, archivando particiones antiguas a almacenamiento frío. Esto mantiene la tabla activa pequeña y los índices eficientes.

Acción 4: Considera el trade-off de consistencia vs. complejidad

Si tu negocio requiere que el encolado sea atómico con otras operaciones (ej. crear pedido + encolar procesamiento de pago), Postgres ofrece esta garantía nativamente. Con Redis o RabbitMQ, necesitas patrones de transacción distribuida que aumentan complejidad y puntos de falla. Para la mayoría de startups, esta consistencia transaccional vale más que el rendimiento marginal adicional de sistemas especializados.

Conclusión

Postgres como sistema de colas no es un hack temporal: es una arquitectura válida y probada para 2026. Con SKIP LOCKED, índices parciales y transacciones bien diseñadas, un solo servidor puede manejar 30.000 ejecuciones por segundo sin sistemas externos. Para founders y CTOs, esto significa menos infraestructura que operar, menos puntos de falla y consistencia transaccional garantizada.

La decisión no es binaria. Comienza con Postgres, monitorea métricas reales de rendimiento, y escala a Redis o RabbitMQ solo cuando los datos muestren que es necesario. La simplicidad arquitectónica es una ventaja competitiva en etapas tempranas.