Qué es PostgreSQL y por qué se volvió el default
Publicado el 2026-09-12 por frfrand
De proyecto universitario a la base relacional que casi todo el mundo elige. Qué la hizo ganar, qué trae de fábrica que sorprende, y los dos ajustes que casi nadie toca y debería.
PostgreSQL empezó en los años ochenta en Berkeley como sucesor de un proyecto llamado Ingres. Durante décadas fue "la otra", la alternativa seria pero menos popular que MySQL.
En los últimos diez años se convirtió en la opción por defecto para proyectos nuevos. Vale ver por qué, porque las razones son concretas.
Qué la hizo ganar
Corrección antes que velocidad. Postgres siempre priorizó comportarse bien en los casos difíciles: transacciones que de verdad son atómicas, restricciones que se cumplen, tipos que no aceptan datos inválidos. Históricamente eso la hacía más lenta en pruebas simples y mucho más confiable en producción.
Un ejemplo que ilustra la filosofía: si intentás guardar un texto más largo que la columna, Postgres da error. Otros motores, durante años, lo truncaban en silencio. Un error es incómodo; un dato mutilado que descubrís seis meses después es peor.
DDL transaccional. Podés meter varios cambios de esquema en una transacción y revertirlos todos si algo falla. Para las migraciones esto es enorme: una migración a medio aplicar es una de las peores situaciones posibles, y con Postgres simplemente no pasa.
Extensible por diseño. Se le pueden agregar tipos, funciones e índices sin tocar el motor. De ahí salieron PostGIS para datos geográficos, TimescaleDB para series temporales, pgvector para búsquedas por similitud. La misma base sirve para cosas que antes requerían un sistema aparte.
Lo que trae y mucha gente no usa
JSONB. Guarda JSON en formato binario, indexable y consultable. Permite empezar con un esquema relacional bien definido y tener un par de columnas flexibles donde hace falta, sin sumar una base de documentos al proyecto.
Arrays y rangos. Una columna puede ser una lista. O un rango de fechas, con operadores para preguntar si dos rangos se solapan — perfecto para reservas, y resuelto sin lógica en la aplicación.
Índices para cada forma de buscar. Además del clásico, hay índices GIN para JSON y texto, índices parciales (que sólo cubren las filas que cumplen una condición y ocupan mucho menos), e índices sobre expresiones.
Vistas materializadas. Una consulta pesada que se guarda como tabla y se refresca cuando vos decís. Resuelve muchos paneles de métricas sin agregar infraestructura.
Los dos ajustes que casi nadie toca
La configuración por defecto de Postgres es conservadora: está pensada para arrancar en cualquier máquina, incluso una muy chica. En un servidor real, dos parámetros cambian mucho:
shared_buffers. Cuánta memoria usa para su caché. El valor por defecto suele ser 128 MB. La recomendación habitual es alrededor del 25% de la RAM del servidor.
work_mem. Memoria por operación de ordenamiento o agrupación. Si es muy chica, esas operaciones se hacen en disco y las consultas se arrastran. Ojo: se multiplica por operación y por conexión, así que subirlo mucho con muchas conexiones puede agotar la memoria.
Y el diagnóstico de siempre: poner EXPLAIN ANALYZE adelante de la consulta lenta. Si la primera línea dice Seq Scan sobre una tabla grande, falta un índice.
Una advertencia sobre conexiones
Cada conexión a Postgres es un proceso del sistema operativo. Eso lo hace muy robusto (un proceso que muere no se lleva a los demás) y también significa que las conexiones son caras.
Una aplicación con muchos trabajadores puede agotar el límite rápido. La solución no es subir el límite: es poner un agrupador de conexiones adelante, como PgBouncer. Es el ajuste que más veces salva a una aplicación que "empezó a fallar cuando creció el tráfico".
En ArduMaker podés levantar Postgres en tu VPS desde el panel, con credenciales, copias de seguridad y acceso por túnel en vez de puerto abierto.