En 2026, simplemente usa Postgres

 (tigerdata.com)
5 puntos por GN⁺ 2026-02-06 | 1 comentarios | Compartir por WhatsApp
  • Postgres es una plataforma unificada capaz de manejar búsqueda, vectores, series de tiempo, colas y más dentro de una sola base de datos
  • Usar varias bases de datos especializadas genera ineficiencias y riesgos en administración, seguridad, respaldos y respuesta ante fallas
  • En la era de la IA, como las bases de datos deben clonarse, probarse y eliminarse rápidamente, una arquitectura de sistema único garantiza simplicidad y agilidad
  • Las extensiones de Postgres usan los mismos algoritmos que Elasticsearch, Pinecone e InfluxDB, entre otros, y su rendimiento ya está comprobado
  • Para la mayoría de las empresas (99%), un solo Postgres es suficiente; las arquitecturas distribuidas complejas solo son necesarias para una minoría muy pequeña de grandes compañías

La necesidad de consolidar bases de datos

  • Se compara la base de datos con una casa, y se explica que Postgres es una estructura que integra varias funciones bajo un mismo techo
    • Permite manejar búsqueda, vectores, series de tiempo, colas y otros casos de uso dentro de un solo sistema
  • En cambio, el consejo de “usar la herramienta adecuada para cada caso” termina llevando a operar varias bases de datos en paralelo
    • Se ponen como ejemplo 7 sistemas: Elasticsearch, Pinecone, Redis, MongoDB, Kafka, InfluxDB y PostgreSQL
    • Hay que administrar por separado el lenguaje de consulta, respaldos, seguridad, monitoreo y respuesta ante incidentes de cada uno
  • Esta estructura distribuida dificulta montar entornos de prueba y resolver problemas, y la complejidad se dispara especialmente cuando hay que responder a fallas de madrugada

Simplicidad en la era de la IA

  • Los agentes de IA necesitan crear, validar y eliminar rápidamente bases de datos de prueba
    • Con una sola base de datos esto puede hacerse con un solo comando, pero con varios sistemas se requiere sincronizar snapshots y ajustar configuraciones
  • Administrar varias bases de datos al mismo tiempo exige un nivel de complejidad propio de I+D
  • En la era de la IA, se subraya que la simplicidad es un elemento indispensable

El mito de la “superioridad” de las bases de datos especializadas

  • Se señala que la idea de que las bases de datos especializadas son mejores para tareas concretas está inflada por el marketing
    • En la práctica, las extensiones de Postgres usan los mismos algoritmos o incluso mejores
  • Según la tabla comparativa, las extensiones de Postgres se corresponden así:
    Función DB especializada Extensión de Postgres Mismo algoritmo
    Búsqueda de texto completo Elasticsearch pg_textsearch BM25
    Búsqueda vectorial Pinecone pgvector + pgvectorscale HNSW/DiskANN
    Series de tiempo InfluxDB TimescaleDB Particionado temporal
    Caché Redis UNLOGGED tables Almacenamiento en memoria
    Documentos MongoDB JSONB Indexación de documentos
    Información geoespacial GIS PostGIS Estándar de la industria
  • pgvectorscale registró una latencia 28 veces menor y un costo 75% menor frente a Pinecone
  • TimescaleDB ofrece un rendimiento igual o mejor que InfluxDB, y pg_textsearch usa el mismo ranking BM25 que Elasticsearch

El costo oculto de distribuir bases de datos

  • Operar varios sistemas multiplica por 7 todos los costos de administración: respaldos, monitoreo, parches de seguridad y respuesta ante fallas
  • Carga cognitiva: hay que aprender distintos lenguajes como SQL, Redis, Elasticsearch DSL, MongoDB, Kafka e InfluxDB
  • Problemas de consistencia de datos: si falla la sincronización entre Postgres y Elasticsearch, se produce deriva de datos
  • Menor disponibilidad: los SLA de varios sistemas se multiplican y reducen la disponibilidad total (ej.: 99.9% × 3 = 99.7%)

El stack moderno de Postgres

  • Las extensiones de Postgres ya llevan años validadas en servicios reales
    • PostGIS (2001), Full-text search (2008), JSONB (2014), TimescaleDB (2017), pgvector (2021)
  • Más de 48,000 empresas usan PostgreSQL, incluidas Netflix, Spotify, Uber, Reddit, Instagram y Discord
  • Extensiones para la era de la IA
    Extensión Sustituye a Características
    pgvectorscale Pinecone, Qdrant Algoritmo DiskANN, latencia 28 veces menor, ahorro de 75% en costos
    pg_textsearch Elasticsearch Implementa BM25 directamente en Postgres
    pgai Pipelines de IA externos Sincroniza automáticamente embeddings cuando cambian los datos
  • Es posible construir una aplicación RAG con un solo Postgres: un solo lenguaje de consulta, un solo respaldo y un solo entorno de pruebas

Ejemplos de extensiones principales

  • pg_textsearch: sustituto de Elasticsearch, con búsqueda basada en BM25
  • pgvector + pgvectorscale: sustituto de Pinecone, con búsqueda vectorial basada en DiskANN
  • TimescaleDB: sustituto de InfluxDB, con compresión de series de tiempo y soporte SQL
  • UNLOGGED tables: sustituto de Redis, para implementar tablas de caché
  • pgmq: sustituto de Kafka, ofrece funcionalidad de cola de mensajes
  • JSONB: sustituto de MongoDB, para almacenar e indexar datos documentales
  • PostGIS: soporte para procesamiento geoespacial
  • pg_cron: automatización de tareas programadas
  • pg_trgm: búsqueda tolerante a errores tipográficos
  • Recursive CTEs: implementación de funciones de exploración de grafos

Conclusión

  • Postgres tiene una estructura con varias habitaciones dentro de una sola casa, integrando distintas capacidades de procesamiento de datos
  • Para la mayoría de las empresas (99%), un solo Postgres es suficiente, y solo una minoría muy pequeña (1%) necesita sistemas distribuidos a hiperescala
  • Se critica la idea de “la herramienta adecuada para cada caso” como una lógica de marketing para vender bases de datos
  • Se propone el principio de empezar con Postgres y agregar complejidad solo cuando realmente haga falta
  • La conclusión final es: en 2026, simplemente usa Postgres

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-06
Comentarios de Hacker News

  • Es incómodo que sea difícil embeber Postgres en apps local-first y que obligue a una configuración con Docker
    Habría sido perfecto si PGlite soportara varias conexiones writer. SQLite también está bien, pero quiero extensiones de PG y soporte real de multi-writer en paralelo

  • Volví a estudiar bases de datos después de mucho tiempo y Postgres de verdad es un sistema casi mágico
    Si metes decenas de millones de filas en varias tablas y defines bien los índices, casi todas las consultas responden en menos de 100 ms
    Si analizas el plan de ejecución, te das cuenta enseguida de qué índices debes agregar, y eso sorprende. Las DB modernas son un verdadero milagro

    • Lo que dices en realidad no es tanto una característica de una DB “moderna”, sino algo que ya era posible incluso con Postgres de hace 20 años
      Claro, ahora es mucho mejor, pero la mayoría de los avances han sido en funciones de consulta avanzadas u optimizaciones operativas
    • Las DB relacionales ya mostraban ese rendimiento desde hace décadas. No es algo exclusivo de Postgres

  • Soy fan de Postgres, pero no estoy de acuerdo con el consejo de “simplemente usa Postgres”
    Está bien construir un stack simplificado con solo Postgres, pero eso no significa que sea eficiente para todas las cargas de trabajo
    En la época de Citus Data, vi muchos casos donde un equipo experto en Postgres tenía que dedicarse de tiempo completo a tuning y operación
    A medida que aumentan los casos de uso basados en IA, la tendencia es adoptar tecnologías especializadas mucho antes
    Hay más detalles en el blog de ClickHouse
    Creo que es mejor un enfoque que aproveche Postgres e integre tecnologías orientadas a un propósito

    • Yo lo entendí no como “usa siempre Postgres”, sino como “considera Postgres como opción por defecto”
    • Yo también soy de la idea de “usa Postgres y cámbialo por otra cosa cuando haga falta”. Un stack simple favorece la iteración rápida en el desarrollo
    • En realidad, dentro de Postgres ya vienen muchas funciones de sistemas especializados. Si lees el manual y haces tuning, puede reemplazar bastante
    • Al final, la clave es que los casos de uso son distintos. Ver comparación entre MySQL y Postgres
    • Creo que el problema es que hoy los desarrolladores se dejan llevar demasiado por el hype y terminan creyendo ciegamente en una tecnología
      Cuando una tecnología se vuelve estándar, el desarrollador se convierte en una pieza intercambiable. Como pasa con los desarrolladores de React
      La unificación tecnológica, desde la perspectiva de la empresa, es una estrategia para facilitar el reemplazo de personal. Hay que proteger la diversidad de herramientas

  • Yo también uso Postgres con frecuencia, pero a veces la simplicidad importa más
    Para exploración de datos o trabajo GIS, Postgres.app es perfecto, pero para un servidor sencillo a veces SQLite puede ser mejor

    • Aunque empieces de forma simple con SQLite, pronto te topas con limitaciones incómodas. Postgres está al nivel de “instálalo y olvídate”
      Incluso en análisis de datos pequeños, Postgres es mucho más rápido que SQLite. La diferencia en índices y funciones es grande
    • SQLite es lo mejor para pruebas de integración. Puedes levantar y bajar la DB fácilmente sin contenedores
    • SQLite también sirve para manejo temporal de datos o como archivo de almacenamiento local.
      Pero en el 99% de los casos uso Postgres. Se siente estable, escalable y mejor que Oracle o MySQL
    • Es incómodo que en Postgres sea difícil configurar permisos para que solo se pueda acceder a cierta DB.
      GRANT ALL PRIVILEGES no siempre funciona
    • La discusión de “qué DB debería usar” tiene demasiadas variables complejas
      Postgres es gratis, rápido y bueno para apps compartidas, pero SQLite es ideal para quien desarrolla en solitario

  • Al final, depende del caso de uso
    Nosotros antes usábamos búsqueda basada en MariaDB y luego nos cambiamos a Elasticsearch, y la velocidad y simplicidad fueron mucho mejores
    Pero para búsquedas simples, Postgres es suficiente.
    Antes de migrar a una herramienta nueva, es mejor esperar, y cambiar solo cuando haga falta es más eficiente

  • DB como Pinecone o Redis son mucho más rentables para ciertos usos
    Pero según la situación, a veces conviene más resolverlo con Postgres.
    Al final hay que decidir según la escala y si existe o no un equipo de operaciones

    • Es más fácil elegir la alternativa correcta una vez que ya existen la app real y los datos
      Postgres basta para la mayoría de las etapas iniciales, y cuando el sistema crezca ya se pueden evaluar otras soluciones

  • Últimamente me estoy moviendo de Postgres a MySQL y SQLite.
    El vacuum, el mantenimiento y los footguns de Postgres son molestos

    • MySQL casi no tiene carga operativa. Postgres requiere atención constante, pero MySQL simplemente funciona
    • SQLite también requiere poco mantenimiento, aunque sí hace falta correr VACUUM para evitar acumulación de espacio
    • MySQL es fácil de administrar, pero hay que renunciar a funciones avanzadas (BRIN, partial index, etc.)
      Aun así, si diseñas bien los índices clusterizados, los range scans son muy rápidos
    • Yo también pensé en cambiarme a MySQL. Las actualizaciones son fáciles, pero su ritmo de evolución es más lento que el de Postgres
    • Es una lástima que se haya detenido el proyecto Zheap de Postgres.
      Hace falta un motor de almacenamiento sin VACUUM. Ver la wiki de Zheap

  • Postgres es excelente, pero tiene dos problemas fundamentales
    Primero, Postgres no es una herramienta integrada sino un conjunto de herramientas, así que la curva de aprendizaje es grande
    Segundo, Postgres tiene un diseño basado en HDD, por lo que puede ser ineficiente en la era de los SSD
    Es muy probable que un RDBMS diseñado solo para SSD sea más simple y más rápido

    • Me da curiosidad de dónde sale eso de que Postgres está basado en HDD. Me gustaría saber la fuente

  • La configuración de clustering (HA) en Postgres es demasiado compleja
    Hay herramientas como Patroni, Spilo y timescaledb-ha, pero son difíciles de administrar y la documentación también es insuficiente
    CloudNativePG es prácticamente la única forma fácil, pero tiene dependencia de Kubernetes
    Ojalá se pudiera armar un replica set de forma tan simple como en MongoDB

    • Pero Postgres no es una DB CP, y en una partición de red puede haber pérdida de escritura
      Para pasar pruebas de Jepsen harían falta cambios estructurales (como en Yugabyte o Neon)

  • Hay opiniones sobre usar Postgres como caché
    Redis es mucho más rápido, pero si la escala es pequeña, Postgres también basta

    • Si necesitas caché, memcache es simple y estable.
      Incluso procesando decenas de miles de millones de solicitudes funciona bien sin reinicios
    • Hay que demostrar con benchmarks si Redis realmente hace falta. Si no hay una diferencia significativa, Postgres basta
    • Al compararlo con Redis, hay que usar unlogged table. Si desactivas las funciones de durabilidad, va mucho más rápido
    • Si la app no tiene necesidades grandes de caché, empieza con Postgres y,
      si tienes una arquitectura de servidores stateless, entonces vale la pena considerar Redis. Si es un proceso de larga vida basado en JVM, también sirve un caché propio
    • La materialized view de Postgres también es bastante útil.
      Pero cuando la carga sube, hace falta un caché externo y hay que renunciar a la consistencia transaccional