PostgreSQL para todo: el #4 que crece mientras el resto cae

PostgreSQL sigue creciendo mientras el resto del top 4 se estanca

En agosto de 2026, PostgreSQL se mantiene como la cuarta base de datos más popular del mundo en el ranking de DB-Engines, con un score de 684,58. Por encima quedan Oracle, MySQL y SQL Server, pero hay una diferencia clave: PostgreSQL es el único del top 4 que crece en el último año, con una variación de +13,32 puntos frente a agosto de 2025 (Oracle, MySQL y SQL Server retroceden entre 60 y 97 puntos en el mismo periodo), según DB-Engines.

La順位 lleva más de doce meses estable en los cuatro primeros puestos, pero la composicion del movimiento cuenta otra historia. Un análisis de abril de 2026 de Simple Talk confirma la misma lectura: PostgreSQL gana terreno lentamente mientras los tres gigantes comerciales pierden fuelle. Para un founder, esto se traduce en una pregunta muy concreta: ¿estás pagando más por mantener tres bases de datos cuando una sola te daría lo mismo?

El argumento de Raphael Bauer: menos sistemas, más velocidad

En un post reciente, Raphael Bauer, CTO e interim manager, defiende una idea provocadora: antes de añadir una nueva pieza a tu stack, pregúntate si PostgreSQL puede hacer el trabajo. Su experiencia recorriendo proyectos desde 2003 con ColumbaDB hasta la analítica web moderna con Privatracker le ha mostrado que mantener múltiples sistemas (Solr, Mongo, Redis, Kafka, ClickHouse) es caro, frágil y consume talento que estaría mejor construyendo producto.

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

Bauer resume el poder de Postgres en tres fuentes: es rock-solid y estable, es fácil de instalar y escalar, y reemplaza a propósito a otros sistemas. La tesis suena extrema, pero los casos que cita lo respaldan: Contentful y Instacart montaron su infraestructura de búsqueda sobre Postgres en lugar de levantar un cluster de Elasticsearch. The Guardian migró de MongoDB a Postgres y publicó el caso. La cobertura del propio Crunchy Data explica cómo usar SELECT FOR UPDATE SKIP LOCKED para convertir una tabla en una cola persistente sin levantar Kafka ni RabbitMQ.

Lo que Postgres puede reemplazar hoy (y lo que no, sin esfuerzo extra)

El artículo de Bauer enumera sustituciones concretas: full-text search (en lugar de Solr o Elasticsearch), JSON nativo (en lugar de MongoDB), colas (en lugar de Kafka/RabbitMQ), time series (en lugar de ClickHouse, vía TimescaleDB), caché (en lugar de Redis, con tablas UNLOGGED), sistema de archivos para blobs binarios, jerarquías (con el tipo LTREE) e incluso parte del middleware de microservicios devolviendo JSON directo desde SQL.

La parte más interesante para un founder en 2026 es la capa de IA. El ecosistema de extensiones maduró rápido: pgvector lleva el vector search a Postgres, pgvectorscale añade el índice StreamingDiskANN para escalar a millones de vectores sin reventar la RAM y pgai llamó modelos de OpenAI, Anthropic, Cohere y Ollama desde SQL. Según Tiger Data, pgvector y pgai están entre las extensiones que más adoptaron sus clientes en 2026, junto a TimescaleDB y PostGIS. En benchmarks internos, pgvector + pgvectorscale alcanzó 28 veces menos latencia y 16 veces más throughput que Pinecone, con 75% menos costo, según la documentación de Tiger Data.

Hay un matiz importante que muchos artículos olvidan: el repositorio de pgai en GitHub fue archivado por su propio dueño en mayo de 2026 y un aviso en el README señala que el proyecto dejó de mantenerse desde febrero de 2026, según timescale/pgai. Para producción, conviene validar el estado actual de la extensión y considerar las extensiones equivalentes que ofrecen los proveedores cloud (Tiger Data, Timescale Cloud, Neon, Supabase) antes de apostar tu RAG a un proyecto sin mantenedor.

¿Qué significa esto para tu startup?

Si estás eligiendo stack ahora mismo, la conversación que le importa a un founder no es Postgres versus Mongo, sino Postgres versus una flota de cinco servicios que necesitan parches, monitoring y DevOps dedicado. Cada servicio adicional es un SRE que no contratas, una vulnerabilidad que no parcheas y una factura cloud que no entiendes. La propuesta «Postgres para todo» reduce superficie de ataque, simplifica backups y baja la barrera para que tu equipo de producto aprenda a operar el sistema.

Acciones concretas para implementar este mes

Audita tu stack de datos. Haz una lista de cuántas bases de datos, colas y cachés corren en producción. Por cada una, pregunta: ¿qué problema concreto resuelve que Postgres no pueda cubrir con una extensión? Si la respuesta es «históricamente lo elegimos así», reevalúa.
Inicia un piloto de pgvector. Si tienes búsqueda por palabra clave en cualquier producto interno o de cara al cliente, prueba pgvector sobre Postgres antes de pagar otro servicio. La migración típica es de días, no meses, y elimina una dependencia externa.
Centraliza tu pipeline de IA. Si tu equipo de producto ya hace calling a OpenAI o Anthropic desde el backend, evalúa mover el orquestador a SQL con una extensión de tipo pgai o el equivalente de tu proveedor. Reduce el código de cuatro round-trips a una sola query, y te deja cambiar de proveedor con un JOIN en lugar de un refactor.

Conclusión

PostgreSQL no va a reemplazar todo, y Bauer lo reconoce al final de su post: hay casos donde una base especializada (ClickHouse para analítica extrema, Redis para latencias sub-milisegundo,Neo4j para grafos masivos) sigue ganando. Pero la conversación en 2026 ya no es «qué base de datos elijo» sino «cuántas bases de datos estoy dispuesto a operar», y la respuesta defendible para una startup en serie seed es cada vez más chica. PostgreSQL, que envejecece mejor que sus competidores en el DB-Engines ranking, es el lugar natural donde empezar a consolidar.