Bases de datos: Parte 3 — PostgreSQL

PostgreSQL — un sistema de gestión de bases de datos objeto-relacional libre, desarrollado por una comunidad internacional independiente. El proyecto comenzó en 1986 en la Universidad de California en Berkeley con el nombre POSTGRES; en 1996 recibió su nombre actual y soporte para SQL. PostgreSQL es conocido por su estricto cumplimiento del estándar SQL, fiabilidad y capacidad de extensión: se le añaden módulos para datos geoespaciales, series temporales, búsqueda de texto completo y búsqueda vectorial.

Licencia y versiones

PostgreSQL se distribuye bajo su propia PostgreSQL License — una licencia permisiva y corta, similar a BSD y MIT. Se puede usar, modificar e integrar en productos comerciales sin pagos y sin la obligación de abrir el código. El proyecto no pertenece a una sola empresa, por lo que el riesgo de un cambio abrupto de condiciones, como ocurre con algunas otras SGBD, es mínimo.

Una nueva versión principal sale una vez al año, normalmente en otoño, y se mantiene durante cinco años. La versión vigente es PostgreSQL 18 (lanzada en septiembre de 2025). El lanzamiento de PostgreSQL 19 en 2026 se retrasa: el equipo planea publicarlo para finales de octubre. El soporte de PostgreSQL 14 finaliza el 12 de noviembre de 2026 — los servidores en esa versión deben actualizarse.

Dentro de una versión principal se publican lanzamientos de corrección (18.1, 18.2, etc.) al menos una vez por trimestre. Siempre deben instalarse: contienen solo correcciones de errores y vulnerabilidades y no cambian el formato de los datos.

Dónde es apropiado PostgreSQL

• Sistemas contables y financieros, ERP, CRM — donde es importante la estricta integridad de los datos y consultas complejas.
• «1С:Предприятие». La plataforma 1С soporta PostgreSQL; para ella se publican compilaciones con ajustes para 1С, incluida la SGBD rusa Postgres Pro de la compañía Postgres Professional. Postgres Pro está incluida en el registro de software ruso y se publica en ediciones Standard, Enterprise y Certified (con certificado FSTEC) — esto es importante para organizaciones que necesitan sustitución de importaciones.
• Aplicaciones web en Django, Ruby on Rails, Laravel, Node.js, donde resultan útiles arrays, JSONB y búsqueda de texto completo.
• Sistemas de información geográfica — con la extensión PostGIS.
• Analítica de volumen medio — las funciones de ventana, las vistas materializadas y la ejecución paralela de consultas permiten generar informes sin un almacén analítico separado.

Cómo está organizado PostgreSQL

MVCC: trabajo concurrente sin interferencias mutuas

PostgreSQL usa control multiversión de concurrencia (MVCC). Al modificar una fila se crea una nueva versión de la misma, y la anterior permanece accesible para las transacciones que comenzaron antes. Gracias a esto, la lectura no bloquea la escritura, y la escritura no bloquea la lectura. Sin embargo, existen bloqueos: dos transacciones que modifican la misma fila se ejecutan de forma secuencial.

La otra cara del MVCC son las versiones obsoletas de filas, que hay que eliminar. Esto lo hace el proceso autovacuum. No se debe desactivar; las transacciones largas y no finalizadas (estado idle in transaction) impiden que funcione y las tablas crecen.

JSONB

El tipo JSONB almacena JSON en forma binaria parseada y permite crear índices sobre él (GIN). En una tabla se pueden combinar columnas estrictas y un campo flexible con atributos arbitrarios — por ejemplo, características de productos de distintas categorías.

Extensiones

Las extensiones añaden nuevos tipos de datos, funciones e índices sin modificar el núcleo:

• PostGIS — geometría y geografía: distancias, intersecciones, búsqueda de objetos en un radio;

• pg_stat_statements — estadísticas de todas las consultas ejecutadas: cuáles son las más frecuentes y cuáles consumen más tiempo. Es lo primero que conviene habilitar en un servidor de producción. El módulo debe cargarse al iniciar el servidor:

  Copy

  # postgresql.conf
  shared_preload_libraries = 'pg_stat_statements'

  luego, en la base de datos ejecutar CREATE EXTENSION pg_stat_statements;;

• TimescaleDB — almacenamiento de series temporales. Las funciones básicas se distribuyen bajo Apache 2.0, y las avanzadas (agregados continuos, compresión, políticas de retención) están bajo la licencia propia del desarrollador: se pueden usar gratis en servidores propios, pero no vender como servicio en la nube;

• pgvector — almacenamiento de vectores y búsqueda de similitud, usado en aplicaciones con modelos de lenguaje.

Configuración básica

Usuario y base para la aplicación

CREATE ROLE shop LOGIN PASSWORD 'надёжный_пароль';
CREATE DATABASE shop OWNER shop;

El propietario de la base obtiene todos los privilegios sobre ella, y los demás usuarios no. Desde la versión 15 los usuarios normales por defecto no pueden crear objetos en el esquema public de una base ajena; esto protege contra toda una clase de errores y ataques.

Quién y desde dónde puede conectarse se define en el archivo pg_hba.conf. Por defecto el servidor escucha solo en localhost; si la aplicación está en otra máquina, en postgresql.conf se indica la dirección concreta en listen_addresses, y en pg_hba.conf — la subred permitida y el método scram-sha-256.

Pool de conexiones

Cada conexión a PostgreSQL es un proceso del sistema operativo. Varias centenas de conexiones concurrentes consumen una cantidad notable de memoria y ralentizan el servidor. Por eso se coloca un pool de conexiones delante de PostgreSQL — con más frecuencia PgBouncer. Mantiene un pequeño número de conexiones reales a la base y las distribuye entre los clientes. Modos de funcionamiento:

• session — la conexión se asigna al cliente durante toda la sesión; es seguro para cualquier aplicación, pero el ahorro es pequeño;
• transaction — la conexión se entrega solo durante la transacción; da la ganancia principal, pero la aplicación no debe depender del estado de sesión (SET, tablas temporales, bloqueos de recomendación entre transacciones).

Copias de seguridad

Copia lógica: pg_dump

pg_dump -Fc -f shop.dump shop
pg_restore -d shop_restored shop.dump

El formato -Fc está comprimido y permite restaurar tablas individuales. pg_dump copia una base; los roles y privilegios a nivel de servidor se guardan por separado con pg_dumpall --globals-only. Las copias lógicas son convenientes para bases pequeñas y para migrar entre versiones principales.

Copia física y recuperación hasta un punto en el tiempo (PITR)

Para bases grandes y la posibilidad de retroceder hasta un minuto concreto se usa la copia física:

1. Habilitan el archivado del registro WAL (write-ahead log) en postgresql.conf:

   Copy

   wal_level = replica
   archive_mode = on
   archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

2. Periódicamente hacen una copia base: pg_basebackup -D /backup/base -Ft -z -P.

3. Durante la recuperación despliegan la copia base, configuran restore_command y, si es necesario, recovery_target_time, crean en el directorio de datos el archivo recovery.signal y arrancan el servidor. PostgreSQL aplicará los registros hasta el momento indicado.

En la práctica esta estrategia se automatiza con herramientas listas — pgBackRest, Barman, WAL-G: gestionan el calendario, el almacenamiento, la verificación de copias y su envío a un almacenamiento compatible con S3.

Errores típicos

• No usar pool de conexiones — la aplicación abre cientos de conexiones y el servidor se queda sin memoria.
• Configuraciones por defecto. Están pensadas para hardware mínimo. Como mínimo hay que ajustar shared_buffers (normalmente alrededor del 25 % de la memoria), effective_cache_size y work_mem.
• Transacciones colgantes. Las sesiones idle in transaction impiden el autovacuum; el parámetro idle_in_transaction_session_timeout las finaliza automáticamente.
• Actualizar la versión principal “in situ”. Los archivos de datos de versiones principales distintas no son compatibles. La migración se realiza con pg_upgrade, copia lógica o replicación lógica — y primero se prueba en una copia.
• Copias sin verificar la restauración. Una copia de seguridad debe restaurarse periódicamente en un servidor de pruebas.

Conclusión

PostgreSQL es una opción sólida por defecto para un proyecto nuevo: licencia libre sin riesgo de cambio de condiciones, transacciones estrictas, tipos de datos y extensiones abundantes. La barrera de entrada es mayor que la de MySQL — habrá que entender la configuración de memoria, el pool de conexiones y las copias de seguridad — pero esos esfuerzos se amortizan en fiabilidad y funcionalidades que no habrá que buscar en otras SGBD.