PostgreSQL en 2026: por qué sigue siendo la base de datos por defecto

Si tienes que arrancar un proyecto nuevo hoy y no sabes qué base de datos usar, la respuesta por defecto en la mayoría de equipos de ingeniería es PostgreSQL. No es una moda pasajera ni el resultado de un hype puntual: es la consecuencia de más de una década de decisiones técnicas acumuladas que han convertido a un motor relacional “aburrido” en la base de datos que mejor absorbe casos de uso que antes exigían herramientas especializadas.

Los números lo confirman. Según el ranking de DB-Engines, PostgreSQL fue el motor con mayor crecimiento durante el primer semestre de 2026, sumando cerca de 22 puntos a su puntuación de popularidad mientras motores como MySQL perdían terreno. Sigue por detrás de Oracle, MySQL y SQL Server en popularidad histórica, pero es el único de los cuatro primeros con una tendencia claramente ascendente.

Un ritmo de publicación que no se nota desde fuera

PostgreSQL sigue un ciclo de una versión mayor al año, publicada habitualmente entre septiembre y octubre. En septiembre de 2026, la versión estable en producción es PostgreSQL 18, con PostgreSQL 19 en fase beta (beta 3 publicada a mediados de agosto, con lanzamiento general previsto para el otoño).

PostgreSQL 18 trajo cambios que no son cosméticos:

• Un nuevo subsistema de E/S asíncrona (AIO) que mejora hasta 3 veces la velocidad de lectura desde almacenamiento en operaciones como sequential scans, bitmap heap scans y VACUUM.
• Skip scans en índices B-tree multicolumna: el planificador ahora puede usar un índice compuesto aunque la consulta omita una condición de igualdad sobre la primera columna del índice, algo que antes obligaba a un sequential scan.
• Columnas generadas virtuales (calculadas en tiempo de consulta, no almacenadas).
• uuidv7() nativo: UUID ordenables por tiempo, que evitan la fragmentación de índices típica de uuidv4() en tablas con muchas inserciones.
• Soporte de autenticación OAuth 2.0, pensado para integrarse con proveedores de identidad corporativos sin depender de LDAP.
• Cláusulas OLD/NEW en RETURNING para INSERT, UPDATE, DELETE y MERGE, útiles para auditoría sin triggers adicionales.

PostgreSQL 19, todavía en beta en el momento de escribir esto, apunta más lejos: autovacuum paralelo, el comando REPACK para reconstruir tablas en caliente sin bloquear escrituras, mejoras de hasta 2x en inserciones bajo carga con claves foráneas, y replicación lógica en línea sin reiniciar el servidor. Ninguna de estas dos versiones reinventa PostgreSQL; cada una lima una fricción operativa concreta que los equipos llevaban años reportando. Ese patrón —evolución constante, sin rupturas— es en sí mismo parte de la respuesta a por qué sigue siendo la opción segura.

La extensibilidad como ventaja estructural

La razón de fondo por la que PostgreSQL absorbe casos de uso nuevos sin que aparezca una base de datos especializada para cada uno es su sistema de extensiones. CREATE EXTENSION permite añadir tipos de datos, índices, funciones y hasta lenguajes procedurales completos sin tocar el núcleo del motor. Esto ha producido un ecosistema que cubre necesidades que en otros motores exigirían migrar a un producto distinto:

• PostGIS para datos geoespaciales, con soporte que rivaliza con bases de datos GIS dedicadas.
• TimescaleDB para series temporales, con particionado automático y compresión columnar.
• pg_cron para tareas programadas dentro de la propia base de datos.
• pg_stat_statements para observabilidad de consultas sin herramientas externas.
• pgvector para búsqueda vectorial y aplicaciones de IA.

pgvector como caso de estudio

pgvector es probablemente el ejemplo más citado en 2026 de por qué la extensibilidad de PostgreSQL importa: cuando la industria necesitó almacenar y buscar embeddings para aplicaciones de RAG y búsqueda semántica, no hizo falta una base de datos vectorial nueva para la mayoría de equipos. Bastó con instalar una extensión sobre la base de datos que ya tenían en producción, con las mismas copias de seguridad, el mismo control de acceso y las mismas herramientas de observabilidad. Le dedicamos un artículo completo a cómo funciona esto por dentro en bases de datos vectoriales, pgvector y embeddings.

Esta capacidad de “traer la funcionalidad a los datos” en lugar de “llevar los datos a una base de datos especializada” reduce la superficie operativa de un sistema: menos motores que parchear, menos réplicas que sincronizar, menos puntos de fallo.

El ecosistema cloud ha cambiado las reglas del juego

Durante años, la objeción práctica a PostgreSQL frente a alternativas gestionadas como DynamoDB o Firestore era operativa: alguien tenía que administrar el servidor, las réplicas y las copias de seguridad. Esa objeción prácticamente ha desaparecido en 2026 gracias a una generación de plataformas que ofrecen PostgreSQL con la experiencia operativa de un servicio serverless.

graph TD
App[Aplicación] -->|SQL / protocolo Postgres| Compute[Cómputo Postgres sin estado]
Compute -->|lecturas y escrituras de páginas| Storage[Capa de almacenamiento multi-tenant]
Storage --> Branch1[Rama: producción]
Storage --> Branch2[Rama: preview de PR]
Storage --> Branch3[Rama: test local]

• Neon separa cómputo y almacenamiento: el proceso de PostgreSQL que atiende tus consultas es efectivamente sin estado, mientras los datos viven en una capa de almacenamiento distribuida propia. Esto habilita branching instantáneo de bases de datos completas (útil para previews de pull requests) y scale-to-zero cuando no hay tráfico. En 2026, Neon fue adquirida por Databricks por mil millones de dólares y amplió su oferta con un conjunto de servicios de backend (auth, almacenamiento de objetos, funciones) en beta, acercándose al terreno de Supabase.
• Supabase toma el camino contrario: ejecuta PostgreSQL prácticamente estándar y lo rodea de un conjunto de servicios listos para usar —autenticación, almacenamiento de archivos, suscripciones en tiempo real, funciones edge— pensados para que un equipo pequeño no tenga que construir ese backend desde cero. En 2026 superó el millón de bases de datos gestionadas.
• Amazon RDS y Aurora PostgreSQL siguen siendo la opción por defecto en organizaciones ya comprometidas con AWS, con Aurora ofreciendo una capa de almacenamiento distribuida propia (con una filosofía similar a la de Neon) y compatibilidad con el protocolo de PostgreSQL.

Rendimiento: ya no es “el motor lento pero fiable”

PostgreSQL cargó durante años con la fama de ser más lento que MySQL en cargas de solo lectura simples. Esa brecha se ha estrechado de forma sostenida: el planificador de consultas basado en costes ha mejorado versión a versión, el subsistema de E/S asíncrona de PostgreSQL 18 reduce la latencia de lecturas desde disco, y JSONB permite modelar documentos semiestructurados con indexación GIN sin sacrificar las garantías transaccionales del motor relacional. La consecuencia práctica es que muchos equipos que antes elegían un motor de documentos solo para tener flexibilidad de esquema, hoy pueden quedarse en PostgreSQL: jsonb cubre esa flexibilidad sin renunciar a JOIN, transacciones ACID completas o restricciones de integridad referencial.

Frente a NoSQL: por qué gana la mayoría de proyectos nuevos

La comparación honesta no es “SQL contra NoSQL” como bloques monolíticos, sino qué modelo de datos y qué garantías necesita tu aplicación concreta. Cubrimos los criterios completos en SQL vs NoSQL: cómo elegir bien en 2026, pero el resumen aplicado a PostgreSQL es este: la mayoría de aplicaciones de negocio tienen datos con relaciones reales entre entidades (usuarios, pedidos, facturas, permisos), necesitan consultas ad hoc que nadie anticipó en el diseño inicial del esquema, y se benefician de transacciones que garanticen que una operación compuesta por varios pasos se aplica entera o no se aplica. Eso es exactamente el terreno donde un motor relacional maduro gana con claridad, y donde forzar un modelo de documentos o clave-valor añade trabajo (desnormalización manual, agregaciones costosas, ausencia de JOIN) sin un beneficio real a cambio.

Las bases de datos NoSQL siguen ganando en escenarios concretos: escritura masiva distribuida geográficamente con tolerancia a partición como prioridad número uno, esquemas verdaderamente poco estructurados y cambiantes, o patrones de acceso por clave que encajan perfectamente en un modelo clave-valor. Pero ese es un subconjunto de proyectos, no la mayoría.

Cuándo PostgreSQL no es la opción por defecto

Ser honesto sobre los límites es parte del trabajo. PostgreSQL no es la mejor opción cuando:

• Necesitas escritura multi-región con baja latencia en cada región y puedes tolerar consistencia eventual: sistemas como DynamoDB o Cassandra están diseñados específicamente para eso.
• Tu carga es predominantemente analítica sobre volúmenes de datos muy grandes (terabytes con consultas agregadas sobre columnas): un almacén columnar como ClickHouse o BigQuery va a rendir mejor de fábrica, aunque extensiones como pg_analytics reducen esa brecha.
• Necesitas más de varios cientos de miles de vectores con búsqueda de altísimo rendimiento y presupuesto para operar un sistema adicional: una base de datos vectorial dedicada puede justificarse, como explicamos en el artículo sobre bases de datos vectoriales.

La recomendación práctica

Si estás arrancando un proyecto nuevo y no tienes un motivo concreto y medido para elegir otra cosa, PostgreSQL sigue siendo la apuesta de menor riesgo en 2026: un ecosistema cloud maduro que quita la fricción operativa, una vía de crecimiento hacia búsqueda vectorial y geoespacial sin cambiar de motor, y una comunidad que sigue publicando mejoras de rendimiento reales versión tras versión. Elige otra cosa cuando tengas un requisito concreto que PostgreSQL no cubre bien — no por defecto.