El Clúster de PostgreSQL
En PostgreSQL, la palabra "clúster" no significa un grupo de máquinas en red como lo hace en casi todas partes del vocabulario de bases de datos.
//
Busca en todas las páginas de la documentación
En PostgreSQL, la palabra "clúster" no significa un grupo de máquinas en red como lo hace en casi todas partes del vocabulario de bases de datos.
Significa la única instancia de servidor en ejecución, y todo lo que esa instancia posee: su directorio de datos, su memoria compartida, sus roles y cada base de datos creada dentro de ella.
initdb, que contiene todas las bases de datos, roles y memoria compartida que esa instancia gestiona conjuntamente.max_connections como un presupuesto compartido, o planificar el aislamiento multi-inquilino.Cada servidor PostgreSQL comienza su vida con un único comando: initdb.
Ese comando crea un directorio en el disco, convencionalmente llamado PGDATA, y todo lo que la instancia del servidor gestionará alguna vez vive dentro de él.
Este directorio PGDATA, más el proceso postmaster en ejecución que lo sirve, es a lo que se refiere la palabra "clúster" en PostgreSQL.
Una analogía útil es un edificio de oficinas: el clúster es el edificio en sí, las bases de datos son los pisos, los esquemas son las habitaciones en cada piso, y las tablas son los archivadores dentro de cada habitación.
Un edificio tiene un solo vestíbulo, un solo conjunto de ascensores y un solo puesto de seguridad, sin importar cuántos pisos tenga.
De la misma manera, un clúster tiene un solo proceso postmaster, una sola región de memoria compartida y un solo conjunto de roles, sin importar cuántas bases de datos vivan dentro de él.
CREATE DATABASE no inicia un nuevo proceso de servidor ni asigna un bloque separado de memoria compartida.
Copia una base de datos plantilla (template1 por defecto) a una nueva entrada de base de datos dentro de la misma instancia en ejecución.
Esa única instancia compartida es también la razón por la que el término es confuso al principio: no tiene nada que ver con el clustering de alta disponibilidad, los conjuntos de réplicas o los grupos de failover gestionados por Patroni, que son un concepto completamente diferente y de nivel superior construido sobre clústeres individuales.
Un único archivo postgresql.conf rige todo el clúster, por lo que configuraciones como shared_buffers y max_connections son presupuestos generales del clúster, no asignaciones por base de datos.
ALTER DATABASE ... SET y ALTER ROLE ... SET le permiten anular configuraciones específicas para una base de datos o rol, pero se superponen a los valores predeterminados generales del clúster en lugar de reemplazar la instancia compartida subyacente.
Los roles son el ejemplo más claro de este alcance compartido, porque un rol creado en una base de datos es visible y utilizable desde todas las bases de datos del clúster, aunque sus privilegios a nivel de objeto normalmente se otorgan por base de datos.
Un proceso backend se conecta a exactamente una base de datos a la vez, y no hay JOIN entre bases de datos incorporado; acceder a otra base de datos en el mismo clúster requiere dblink o un wrapper de datos foráneos, tratándola casi como un servidor remoto.
-- Hechos generales del clúster frente a hechos por base de datos
SHOW data_directory; -- una ruta, clúster completo
SELECT datname FROM pg_database; -- cada base de datos que posee este clúster
SELECT rolname FROM pg_roles; -- los roles son visibles en todo el clústerLos tablespaces le permiten colocar bases de datos, tablas o índices individuales en discos físicos diferentes mientras permanecen dentro del mismo clúster lógico, lo cual es una decisión de diseño de almacenamiento en lugar de una decisión de aislamiento.
WAL (write-ahead log) se genera como un único flujo general del clúster, que es exactamente por qué la replicación y la recuperación en un punto en el tiempo se configuran una vez por clúster en lugar de una vez por base de datos.
Debido a que el flujo WAL y el grupo de búferes compartidos son generales del clúster, un pico de actividad de escritura en una base de datos compite directamente por el mismo presupuesto de E/S y memoria que cualquier otra base de datos en esa instancia.
Las actualizaciones de versión principal operan sobre todo el clúster a la vez, ya que pg_upgrade migra todas las bases de datos en PGDATA juntas y no hay forma de ejecutar PostgreSQL 17 para una base de datos y PostgreSQL 18 para otra dentro de la misma instancia.
Esa restricción de versión única es una entrada de planificación real para sistemas multi-inquilino, ya que significa que cada inquilino que comparte un clúster se ve obligado a seguir el mismo calendario de actualizaciones, independientemente de si están listos para ello o no.
max_connections es la restricción de recurso compartido más crítica en la práctica, ya que se establece una vez para todo el clúster y cada base de datos, cada rol y cada aplicación compiten por el mismo grupo de ranuras de backend, que es exactamente por qué la agrupación de conexiones es importante incluso en un clúster con poca carga.
La granularidad de la copia de seguridad sigue la misma división que todo lo demás: pg_basebackup captura todo el clúster como una unidad física, mientras que pg_dump puede dirigirse a una sola base de datos para una copia de seguridad lógica y más selectiva.
Los límites de seguridad necesitan la misma corrección, porque las credenciales de inicio de sesión de un rol funcionan en todas las bases de datos del clúster, aunque las sentencias GRANT delimitan sus privilegios reales por base de datos o por objeto, por lo que "base de datos diferente" no es la misma garantía que "inicio de sesión diferente".
| Enfoque de aislamiento | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Esquema por inquilino, una base de datos | Más barato; pool de conexiones único; informes fáciles entre inquilinos | Aislamiento más débil; una consulta incorrecta afecta a todos | Equipos pequeños, bajo número de inquilinos, inquilinos de confianza |
| Base de datos por inquilino, un clúster | Aislamiento más fuerte; copia de seguridad/restauración por base de datos | Todavía comparte max_connections, búferes compartidos y actualizaciones de versión | SaaS de tamaño mediano que busca aislamiento sin nueva infraestructura |
| Clúster por inquilino | Aislamiento completo de recursos y versión | Mayor costo operativo; más instancias para parchear y monitorear | Inquilinos regulados o de alto valor que necesitan aislamiento estricto |
initdb, sin importar cuán confusa sea esa superposición con el vocabulario moderno de HA.postmaster en ejecución sirven a todas las bases de datos en PGDATA, por lo que todo el clúster se actualiza conjuntamente a través de pg_upgrade.postmaster, lo que interrumpe todas las bases de datos del clúster a la vez.max_connections, búferes compartidos y rendimiento WAL, por lo que las ganancias de aislamiento vienen con compensaciones reales de recursos compartidos.Se refiere a una instancia de servidor y su directorio de datos (PGDATA), creada por una sola llamada a initdb, junto con cada base de datos y rol que esa instancia gestiona.
Un clúster es toda la instancia en ejecución; una base de datos es uno de los muchos contenedores lógicos posibles dentro de esa instancia, cada uno con sus propias tablas y esquemas, pero compartiendo los roles y recursos del clúster.
Sí, siempre: un binario sirve a todo el clúster, por lo que una actualización de versión principal a través de pg_upgrade mueve todas las bases de datos de ese clúster juntas.
Sí: un rol creado en una base de datos es visible y puede iniciar sesión desde cualquier base de datos en el mismo clúster, aunque sus privilegios reales se otorgan por base de datos u objeto.
No: un backend se conecta a una base de datos a la vez, por lo que el acceso entre bases de datos requiere dblink o un wrapper de datos foráneos en lugar de un JOIN nativo.
Por clúster: es un presupuesto compartido de ranuras de conexión de backend por el que compiten cada base de datos y cada aplicación, que es una razón importante por la que la agrupación de conexiones es importante.
CREATE DATABASE funciona copiando una base de datos plantilla existente, template1 por defecto, a una nueva entrada dentro del mismo clúster en lugar de iniciar un nuevo proceso de servidor.
No: un reinicio detiene e inicia el único proceso postmaster para todo el clúster, por lo que todas las bases de datos de esa instancia se detienen y vuelven a iniciarse juntas.
Un tablespace es una decisión de ubicación de almacenamiento, que le permite colocar datos en un disco diferente; una base de datos es un límite de aislamiento lógico para tablas y esquemas, y cualquiera de ellos puede usar cualquier tablespace en el clúster.
Utilice base de datos por inquilino cuando necesite un mayor aislamiento y copias de seguridad y restauraciones por inquilino, y pueda aceptar que los inquilinos todavía comparten el límite de conexiones del clúster y el calendario de actualizaciones de versión.
Cuando los requisitos regulatorios o las preocupaciones sobre el radio de explosión exigen un aislamiento completo de recursos y versiones, ya que un clúster separado es la única opción que elimina por completo las max_connections compartidas, los búferes compartidos y el tiempo de actualización.
No directamente: Patroni gestiona el failover de alta disponibilidad entre clústeres de PostgreSQL (un primario y sus réplicas), mientras que "clúster" en sí mismo solo describe una de esas instancias individuales.
initdb en el discoVersiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, línea de mantenimiento 17).
Revisado por Chris St. John·Última actualización: 15 jul 2026