> ## 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 aislamiento PostgreSQL dedicado o compartido para un servicio de tenant BYOC compatible. 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 PostgreSQL correspondientes `DATABASE` y `SCHEMA`. ## Elige `DATABASE` (`dedicated`) cuando predomina el aislamiento *** Usa una base de datos PostgreSQL dedicada por tenant cuando necesites un límite de infraestructura fuerte, ventanas independientes de mantenimiento de base de datos o un plan de recuperación diseñado alrededor de una base dedicada. Ejemplos habituales son una institución muy regulada, un tenant de alto volumen o uno cuya carga no debe compartir una instancia PostgreSQL con otros tenants. Esta opción aumenta el costo de infraestructura y operación, así que valida primero el diseño de conexiones, backups y migraciones del producto. ## Elige `SCHEMA` (`shared`) cuando predomina la densidad *** Usa un esquema dedicado por tenant en una base PostgreSQL compartida cuando el producto compatible pueda operar en modo `shared` y tu modelo operativo valore densidad y menor costo de infraestructura por tenant. Un incidente o acción de mantenimiento a nivel de base puede afectar a tenants de la instancia compartida. Planifica capacidad, backups, recuperación y mantenimiento para ese radio de impacto compartido. ## Trata la migración como una operación de producto *** No dependas de una promoción automática genérica de `SCHEMA` a `DATABASE`. Mover un tenant a almacenamiento dedicado exige una migración planificada por el operador que el producto objetivo soporte. Antes de cambiar un registro, define: 1. el procedimiento de migración compatible con el producto objetivo; 2. un plan probado de backup, consistencia y rollback; 3. una ventana de mantenimiento y plan de comunicación; y 4. comprobaciones posteriores de autenticación, enrutamiento y datos del tenant. ## Lista de decisión *** | Pregunta | Favorece `DATABASE` | Favorece `SCHEMA` | | :-------------------------------------------------------------------------------- | :------------------ | :---------------- | | ¿El tenant requiere un límite de base de datos dedicado? | Sí | No | | ¿Puede el tenant compartir dominio de mantenimiento e incidentes a nivel de base? | No | Sí | | ¿Es aceptable el costo de infraestructura por tenant? | Sí | No | | ¿El producto admite explícitamente el modo elegido? | Obligatorio | Obligatorio | ## Páginas relacionadas *** Soporte por producto, alcance de solicitudes y conceptos de almacenamiento. Cómo los registros de servicio de tenant aprovisionan recursos compatibles.