> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Casos de uso de multi-tenancy > Elige el aislamiento de PostgreSQL dedicado o compartido para un servicio de tenant BYOC admitido. Elige un modo de aislamiento por servicio de tenant después de confirmar que el producto admite multi-tenancy. En los registros de Tenant Manager, los valores son `dedicated` y `shared`. Esta página usa los conceptos de PostgreSQL correspondientes `DATABASE` y `SCHEMA`. ## Elige `DATABASE` (`dedicated`) cuando domina el aislamiento *** Usa una base de datos PostgreSQL dedicada por tenant cuando el tenant necesita un límite de infraestructura fuerte. Lo mismo se aplica cuando el tenant necesita ventanas de mantenimiento de base de datos independientes, o un plan de recuperación diseñado en torno a una base de datos dedicada. Los ejemplos típicos incluyen una institución muy regulada, un tenant de alto volumen o un tenant cuya carga de trabajo no debe compartir una instancia de PostgreSQL con otros tenants. Esta elección aumenta el costo de infraestructura y operativo, así que valida primero el diseño de conexión, backup y migración del producto. ## Elige `SCHEMA` (`shared`) cuando domina la densidad *** Usa un esquema dedicado por tenant en una base de datos PostgreSQL compartida cuando tu modelo operativo valora la densidad y un menor costo de infraestructura por tenant. El producto admitido también debe poder operar en el modo `shared`. Un incidente o una acción de mantenimiento en el nivel de base de datos puede afectar a los tenants de la instancia compartida. Planifica la capacidad, los backups, la recuperación y el mantenimiento en torno a ese radio de impacto compartido. ## Trata la migración como una operación del producto *** No dependas de una promoción automática genérica de `SCHEMA` a `DATABASE`. Mover un tenant a almacenamiento dedicado requiere una migración planificada por el operador que el producto objetivo admita. Antes de cambiar un registro, establece: 1. el procedimiento de migración admitido del producto objetivo 2. un plan probado de backup, consistencia y rollback 3. una ventana de mantenimiento y un plan de comunicación 4. verificaciones posteriores a la migración para la autenticación, el enrutamiento y los datos del tenant. ## Checklist de decisión *** | Pregunta | Favorece `DATABASE` | Favorece `SCHEMA` | | :------------------------------------------------------------------------------------------------ | :------------------ | :---------------- | | ¿El tenant requiere un límite de base de datos dedicado? | Sí | No | | ¿El tenant puede compartir un dominio de mantenimiento e incidentes en el nivel de base de datos? | No | Sí | | ¿Es aceptable el costo de infraestructura por tenant? | Sí | No | | ¿El producto admite explícitamente el modo seleccionado? | Obligatorio | Obligatorio | ## Páginas relacionadas *** Compatibilidad por producto, alcance de las solicitudes y conceptos de almacenamiento. Cómo los registros de servicio de tenant aprovisionan los recursos admitidos.