Fundamentos de PostgreSQL
PostgreSQL es una base de datos relacional de código abierto y compatible con estándares que combina un motor SQL estricto con un sistema extensible de tipos e índices diseñado para ser extendido en lugar de reemplazado.
//
Busca en todas las páginas de la documentación
PostgreSQL es una base de datos relacional de código abierto y compatible con estándares que combina un motor SQL estricto con un sistema extensible de tipos e índices diseñado para ser extendido en lugar de reemplazado.
Esta página sienta las bases conceptuales para el resto del grupo PostgreSQL Core & SQL: cómo se relacionan entre sí un clúster, una base de datos, un esquema y una tabla, cómo se ejecuta realmente una sola consulta bajo el capó y en qué se diferencian las decisiones de diseño de PostgreSQL de otros sistemas relacionales.
Un servidor PostgreSQL en ejecución se llama clúster, y un solo clúster puede alojar muchas bases de datos independientes, aunque la palabra "clúster" no tiene nada que ver con múltiples máquinas.
Cada base de datos es un espacio de nombres separado para esquemas, y una conexión de cliente se adjunta a exactamente una base de datos durante toda su sesión.
Dentro de una base de datos, un esquema agrupa tablas, vistas, funciones y otros objetos relacionados, de la misma manera que las carpetas agrupan archivos.
PostgreSQL incluye un esquema predeterminado llamado public, pero los sistemas de producción suelen definir sus propios esquemas para separar aplicaciones, inquilinos o módulos lógicos.
Cada objeto que crea, desde una tabla hasta un tipo personalizado, es en sí mismo una fila en una tabla de catálogo del sistema, por lo que PostgreSQL puede describir su propia estructura utilizando SQL ordinario.
Piense en el clúster como un archivador, cada base de datos como un cajón, cada esquema como una carpeta dentro de ese cajón y cada tabla como una carpeta etiquetada dentro de esa carpeta.
PostgreSQL también implementa el estándar SQL de cerca, lo que significa que la mayoría de la sintaxis SELECT, JOIN y de restricciones será familiar para cualquiera que provenga de otra base de datos relacional.
Donde PostgreSQL diverge del estándar, generalmente agrega capacidad en lugar de reemplazarla, como los tipos nativos de array y JSON junto con los tipos escalares estándar.
Un clúster de PostgreSQL se ejecuta como un proceso supervisor llamado postmaster, que escucha nuevas conexiones y crea un proceso backend dedicado para cada una.
Ese modelo de un proceso por conexión significa que cada sesión obtiene un aislamiento completo de otras sesiones, pero también significa que el recuento de conexiones consume directamente memoria y sobrecarga de planificación de CPU.
Cuando un backend recibe una consulta, PostgreSQL analiza el texto SQL en un árbol de análisis, lo reescribe de acuerdo con las vistas o reglas, y lo entrega al planificador.
El planificador es un optimizador basado en costos que estima la forma más barata de satisfacer la consulta utilizando estadísticas de tablas y columnas recopiladas por ANALYZE.
El plan elegido se entrega al ejecutor, que extrae filas a través de un árbol de operadores como escaneos secuenciales, escaneos de índice, uniones y ordenaciones.
Debajo de todo esto, PostgreSQL utiliza el control de concurrencia multiversión, o MVCC, para que los lectores nunca bloqueen a los escritores y los escritores nunca bloqueen a los lectores.
MVCC funciona manteniendo múltiples versiones de una fila y permitiendo que cada transacción vea una instantánea coherente basada en cuándo comenzó.
Cada cambio se registra primero en el registro de escritura anticipada (write-ahead log), o WAL, antes de que la página de datos correspondiente se modifique en memoria, que es lo que hace posible la recuperación ante fallos.
Las versiones de fila antiguas que ya no son visibles para ninguna transacción se convierten en tuplas muertas, y el proceso autovacuum recupera ese espacio en segundo plano.
cliente -> postmaster (crea) -> backend
backend: parse -> rewrite -> plan -> execute
execute: registro WAL -> búferes compartidos -> (checkpoint) -> disco
Este pipeline, desde el análisis hasta el WAL y el disco, es la razón por la que PostgreSQL puede garantizar la durabilidad y al mismo tiempo agrupar las escrituras físicas para obtener rendimiento.
El diseño impulsado por catálogos de PostgreSQL también es lo que lo hace extensible sin bifurcar el motor principal, ya que extensiones como pgvector o PostGIS simplemente registran nuevos tipos, operadores y métodos de acceso a índices en las mismas tablas de catálogo que utiliza el motor principal.
A partir de PostgreSQL 18.4, el proyecto sigue un ciclo de lanzamiento de versiones principales anual, con 18 como la línea estable actual y 17 todavía recibiendo actualizaciones de mantenimiento.
Esa cadencia predecible es importante para planificar las actualizaciones, ya que cruzar una versión principal generalmente requiere una exportación/restauración lógica o un corte de replicación lógica en lugar de un intercambio binario en el lugar.
Un solo clúster de PostgreSQL escala verticalmente bastante bien, pero eventualmente las cargas de trabajo necesitan distribuir lecturas, escrituras o ambas a través de más de un nodo.
La replicación en streaming, la agrupación de conexiones y las extensiones diseñadas específicamente abordan diferentes partes de ese problema de escalado, y recurrir a la incorrecta para la carga de trabajo es un error común de arquitectura.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Escalado vertical (primario más grande) | Más simple de operar, sin complejidad distribuida | Alcanza límites de hardware, punto único de fallo | La mayoría de las cargas de trabajo antes de que el volumen de lectura/escritura supere una máquina |
| Réplicas de lectura (replicación en streaming) | Descarga el tráfico de lectura, barato de añadir | Retraso de replicación, sin capacidad de escritura adicional | Aplicaciones con muchas lecturas e informes |
| Agrupación de conexiones (PgBouncer) | Reduce la sobrecarga del backend/conexión sin cambios en la aplicación | Añade un salto, la agrupación en modo transacción rompe algunas características de sesión | Aplicaciones de alta concurrencia con muchas conexiones de corta duración |
| PostgreSQL administrado (RDS, Cloud SQL) | Descarga el parcheo, copias de seguridad y failover al proveedor | Menos control sobre extensiones y ajuste del kernel | Equipos sin capacidad dedicada de operaciones de bases de datos |
Ninguno de estos enfoques reemplaza a los otros, y la mayoría de los sistemas de producción combinan varios de ellos a medida que crece la carga.
shared_buffers requieren un reinicio completo.Un clúster es el proceso del servidor en ejecución y su directorio de datos, mientras que una base de datos es un espacio de nombres dentro de ese clúster que comúnmente comparte el clúster con varias bases de datos hermanas.
Significa que una consulta de informe de larga ejecución nunca bloquea una escritura concurrente, una escritura nunca tiene que esperar a que terminen los lectores, y cada transacción simplemente ve una instantánea coherente de los datos en lugar de cambios parciales de otros.
Cada cambio se registra de forma duradera en el WAL antes de que la página en memoria se considere confirmada, que es lo que permite a PostgreSQL reproducir el WAL desde el último punto de control y reconstruir cualquier estado en memoria perdido después de un fallo.
Una recarga relee postgresql.conf para configuraciones que se pueden cambiar en vivo, mientras que un reinicio recicla el postmaster y todos los backends, lo cual es necesario para configuraciones como shared_buffers que se fijan al inicio.
No para empezar, pero entender que el planificador reordena y reescribe tu SQL explica la mayoría de las sorpresas de "por qué esto es lento" más adelante.
Debido a que los tipos, operadores y métodos de acceso a índices son solo filas en tablas de catálogo del sistema, las extensiones pueden registrar nuevos sin parchear el código fuente del motor principal.
Las tuplas muertas se acumulan, las tablas se hinchan y, en el peor de los casos, el clúster se acerca al desbordamiento de ID de transacción, lo que obliga a PostgreSQL a entrar en un modo de limpieza protector y disruptivo.
Sí; 18 es la versión principal estable actual, y 17 permanece en la línea de mantenimiento compatible para equipos que aún no están listos para actualizar.
Una extensión puede agregar nuevos tipos de datos, operadores y métodos de acceso a índices que participan en el planificador y el ejecutor exactamente como los incorporados, no solo agregar funciones llamables.
Sí, usando bases de datos separadas o esquemas separados, aunque cada límite de aislamiento tiene diferentes implicaciones para el alcance de la copia de seguridad y la contabilidad de conexiones.
Cada conexión es un proceso backend completo que consume memoria y compite por la planificación de la CPU, por lo que cientos de conexiones inactivas son baratas, pero cientos de conexiones activas no lo son.
Porque su modelo de durabilidad, escrituras WAL-antes-de-página-de-datos más reproducción en caso de fallo, ha sido estable y probado en batalla durante décadas, y se han agregado nuevas características alrededor de ese núcleo en lugar de reemplazarlo.
Versiones de la pila: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.
Revisado por Chris St. John·Última actualización: 15 jul 2026