Base de datos dedicada versus compartida: rendimiento y aislamiento

La documentación oficial de Microsoft sobre la arquitectura de aplicaciones SaaS multiinquilino distingue tres modelos de arrendamiento, generalmente denominados Silo (recursos dedicados por inquilino), Pool (recursos totalmente compartidos) y Bridge (una mezcla de los dos, algunos inquilinos aislados, otros compartidos). Estos tres modelos se aplican directamente a Postgres, a nivel de esquema, base de datos o clúster completo.

Concretamente, para un backend de Postgres, esto proporciona tres arquitecturas distintas. El esquema compartido (una base única, una columna tenant_id, políticas RLS que filtran las filas) es el modelo Pool más común en las guías multiinquilino: económico, pero la frontera entre dos clientes se convierte en una expresión SQL evaluada tabla por tabla. La base por inquilino en un clúster compartido es un modelo Bridge intermedio: cada inquilino tiene su propia base Postgres (un comando CREATE DATABASEreal), pero varias bases coexisten en el mismo clúster físico, por lo que comparten CPU, IO y conexiones. El clúster totalmente dedicado por inquilino es el modelo de silo completo: recursos de CPU, RAM y IO completamente aislados, generalmente reservados para inquilinos con alto cumplimiento o problemas de carga.

Terminología Silo/Pool/Bridge: documentación oficial de Microsoft, patrones de arquitectura SaaS multiinquilino (Azure Architecture Center).

El modelo intermedio, base por inquilino en un clúster compartido, a menudo está ausente en las guías que presentan la elección binaria entre “una base única para todos” y “un servidor por cliente”. Sin embargo, este es el que Aurabase utiliza por defecto, como se detalla a continuación.

La elección entre estos tres modelos surge con cada decisión de arquitectura multiinquilino, no solo con un proveedor de BaaS: un equipo que construye su propio backend SaaS en Postgres administrado (RDS, Cloud SQL o una instancia autohospedada) realiza exactamente el mismo arbitraje, con los mismos mecanismos de contención en juego una vez que varios clientes se colocan en la misma instancia física.

Un noisy neighbor (vecino ruidoso) es un inquilino que consume una parte desproporcionada de los recursos compartidos de una infraestructura, en detrimento de otros inquilinos en el mismo servidor. El término proviene de la nube pública, pero se aplica directamente a un clúster de Postgres compartido: una base de datos puede degradar el rendimiento de otras sin siquiera tocar sus datos.

Seis mecanismos aparecen con mayor frecuencia en producción:

• Contención de CPU: una consulta costosa (unión sin índice, clasificación masiva) consume ciclos de CPU que el kernel comparte entre todas las bases de datos activas en el clúster.
• Contención de IOPS: una copia de seguridad, un VACUUM FULL o una importación masiva satura el rendimiento del disco del clúster, lo que ralentiza las lecturas y escrituras en otras bases de datos.
• Agotamiento de la conexión: max_connections limita el número de conexiones activas en todo el nivel del clúster, no por base. Una base que se abre demasiado reduce el margen de los demás.
• Contención de autovacuum: autovacuum se ejecuta con un número limitado de trabajadores por clúster; una base de datos con una alta tasa de escritura puede retrasar la limpieza de las tablas de otra base de datos.
• Expulsión de caché: shared_buffers es una memoria única para todo el clúster; una base de datos con un conjunto de trabajo grande puede desalojar las páginas almacenadas en caché de una base de datos vecina más pequeña.
• Ventanas de mantenimiento compartidas: la copia de seguridad, la conmutación por error de la réplica o la actualización importante se aplican a todo el clúster, no por base.

Esquema estructural, no resultado de medición: hasta la fecha no se han publicado datos comparativos de rendimiento para estas dos topologías.

El presupuesto de conexión suele ser el síntoma más visible en producción, incluso antes de la latencia. Este es el tema detallado de nuestra guía de ajuste de max_connections y nuestra comparación de PgBouncer, Supavisor y PgCat.

Un pooler en modo de transacción (PgBouncer, Supavisor, PgCat) mitiga el agotamiento de la conexión, pero no elimina la contención de CPU o IOPS: reutiliza las conexiones de servidor existentes, no agrega núcleos de CPU ni rendimiento de disco adicionales al clúster. Nuestro artículo sobre el modo de agrupación de transacciones detalla qué cambia realmente este modo y qué no cambia.

La seguridad a nivel de fila resuelve un problema diferente: evita que una consulta lea o modifique las filas de otro inquilino, en el nivel lógico. No reserva ningún ciclo de CPU, ni ranura de conexión, ni rendimiento de disco para un inquilino específico.

Dos inquilinos pueden tener políticas RLS perfectamente herméticas y degradarse mutuamente al mismo tiempo: el vecino ruidoso es un problema de recursos físicos, no de derechos de acceso. Confundir ambos conduce a una falsa sensación de seguridad operativa una vez que la EPIRB está instalada.

El código de aprovisionamiento (aura-provisioner) documenta exactamente dos arquitecturas posibles para un proyecto de Postgres activo, a partir de una consolidación de aprovisionamiento a la que el código se refiere como Tarea 12: FullyDedicated y SharedClusterDedicated. Los modelos heredados basados ​​en esquemas se han eliminado de la ruta de aprovisionamiento.

El nivel enterprise activa FullyDedicated: un clúster CNPG completo, reservado para este único proyecto. Todos los demás niveles (gratuito, profesional, equipo) se dirigen a SharedClusterDedicated: una base de datos Postgres project_<uuid> completa, en el clúster CNPG de la organización del proyecto. Por lo tanto, no es un esquema compartido: incluso en un plan estándar, su base de datos es una base de datos Postgres completa, no una línea entre otras en una tabla común. Lo que se comparte es el cluster (CPU, RAM, disco, conexiones), no la base en sí.

El clúster CNPG de una organización se crea cuando se aprovisiona su primer proyecto de Postgres y nunca hospeda un proyecto de otra organización, una opción de diseño bloqueada en el nivel de código (org_cluster.rs, bloqueo de asesoramiento de Postgres por organización en el momento de la creación). Por lo tanto, el único posible vecino ruidoso en el rellano compartido de Aurabase es otro proyecto de su propia organización, nunca el de un cliente externo.

/// Capacidad nominal (número de bases de proyectos) de un cluster organizacional.
/// Umbral de observabilidad: más allá de este, orientar la organización hacia FullyDedicated.
/// Controlable a través de FLEET_CLUSTER_CAPACITY (predeterminado 1000, limitado [1, 1_000_000]).
pub fn fleet_cluster_capacity() -> i32 {
    std::env::var("FLEET_CLUSTER_CAPACITY")
        .ok()
        .and_then(|v| v.parse::<i32>().ok())
        .filter(|n| (1..=1_000_000).contains(n))
        .unwrap_or(1000)
}

Especificaciones de la arquitectura del clúster PostgreSQL gestionado por Aurabase.

Este umbral de 1000 bases por clúster no es un límite estricto: es un punto de referencia de observabilidad que genera una recomendación para migrar a FullyDedicated, no un bloqueo automático. Ya no impulsa ninguna decisión de ubicación, ahora solo es posible un grupo por organización.

Cada cluster, dedicado o de flota, expone un CNPG Pooler (PgBouncer) que absorbe parte de la presión sobre las conexiones activas, en ambas topologías. A continuación se detalla lo que este agrupador realmente cambia para la contención de recursos.

El tamaño de CPU/RAM de un clúster compartido tampoco es uniforme entre organizaciones: se deriva del nivel de la organización a través de una función dedicada (FleetSizing::from_org_plan, verificada en org_cluster.rs), y no de un tamaño único aplicado a todos los niveles. Una organización a nivel de equipo no dimensiona su clúster de la misma manera que una organización a nivel libre.

Estas dos arquitecturas se ejecutan en PostgreSQL 16, no en la versión 17, verificadas en el Dockerfile de la imagen CNPG utilizada en producción. Esta elección de versión tiene sus propias implicaciones de ajuste, detalladas en nuestra comparación Postgres 16 vs 17 vs 18.

Para proyectos sujetos a una obligación contractual de aislamiento físico documentado, nuestras páginas de cumplimiento DPA y detallan lo que cubre cada nivel.

La desventaja del modelo base por inquilino, destacada por varias herramientas de gestión de migración de esquemas como Bytebase, es operativa más que técnica: cada migración debe aplicarse y verificarse en cada base, una por una, incluso cuando coexisten en el mismo clúster. Un clúster totalmente dedicado no elimina este costo, incluso lo agrega: una migración por clúster para monitorear de forma independiente, en lugar de solo una.

Los recursos especializados en arquitectura de software multiinquilino, como CodeOpinion, presentan regularmente este enfoque intermedio (por inquilino en infraestructura compartida) como un compromiso razonable entre el esquema compartido y el clúster totalmente dedicado, en lugar de una elección binaria entre los dos extremos.

Pasar de compartido a dedicado no requiere reescribir un esquema ni cambiar de motor: en ambos casos, es Postgres, con la misma cadena pg_dump / pg_restore que la descrita en nuestra guía de migración de Supabase a Aurabase. Cambiar el nivel sigue siendo una operación de alternancia, no una reescritura de la aplicación.

La base dedicada y la base compartida no entran en conflicto con la seguridad de los datos: ambos modelos pueden aislar correctamente a un inquilino de otro en el nivel lógico. Se oponen entre sí en cuanto a recursos físicos (CPU, IOPS, conexiones, caché, ventanas de mantenimiento). Es este plan el que define a un vecino ruidoso, no una política RLS mal redactada.

El modelo Aurabase, verificado en el código del aprovisionador, conserva por defecto un compromiso intermedio: una base de datos Postgres dedicada por proyecto, en un clúster compartido pero estrictamente reservado para una sola organización, con un clúster totalmente dedicado reservado para el nivel empresarial. La elección correcta depende de tus limitaciones reales, no de un reflejo en el que la dedicación siempre sería la mejor opción.