> ## 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 > Consulta ejemplos prácticos que muestran cuándo elegir aislamiento DATABASE frente a SCHEMA, con una ruta de migración clara para pasar entre ellos. Elegir un modo de aislamiento es un balance entre **fuerza de aislamiento** y **costo operativo**. Esta página recorre dos escenarios realistas — uno para cada modo — y muestra cómo un despliegue puede comenzar en un modo y migrar al otro a medida que crece. Para la comparación completa de modos, consulta [Modos de aislamiento en Multi-tenancy](/es/multi-tenancy#modos-de-aislamiento). ## Cuándo elegir cada modo *** Aislamiento máximo — una base de datos separada por tenant. Ideal cuando los tenants son grandes, regulados o sensibles a vecinos ruidosos y puedes absorber un mayor costo por tenant. Aislamiento eficiente — un esquema separado por tenant dentro de una base de datos compartida. Ideal para muchos tenants más pequeños donde la densidad y la eficiencia de costos importan más. ## Ejemplo 1 — Fintech regulada de alto volumen *** **"Banco ACME"** es una institución financiera autorizada que procesa un alto volumen de transacciones bajo estricta supervisión regulatoria. **Requisitos:** * Aislamiento físico fuerte para satisfacer a auditores y reguladores. * El menor radio de impacto posible — un incidente que afecte a un tenant no debe tocar a los demás. * La capacidad de respaldar y restaurar un solo tenant de forma independiente, incluida la recuperación a un punto en el tiempo. * Rendimiento predecible bajo carga pesada y sostenida. **Modo recomendado: `DATABASE`** Banco ACME corre en modo `DATABASE`. Cada tenant obtiene una base de datos PostgreSQL dedicada, de modo que: * El aislamiento físico es completo — no hay superficie de esquema compartida entre tenants. * El radio de impacto de cualquier fallo, migración o restauración queda confinado a un solo tenant. * Una restauración selectiva toca únicamente la base de datos del tenant afectado, sin impacto en los demás. * El aislamiento de rendimiento es fuerte, ya que los tenants no comparten espacio de tablas ni compiten dentro de la misma base de datos. El mayor costo de infraestructura por tenant del modo `DATABASE` se justifica aquí por los requisitos regulatorios y de aislamiento — y por volúmenes de transacciones que harían valioso el aislamiento de rendimiento por sí solo. ## Ejemplo 2 — Startup en etapa temprana *** **"FinX"** es una startup en etapa temprana que incorpora rápidamente muchos clientes pequeños, con restricciones de costo ajustadas y un volumen modesto por tenant. **Requisitos:** * Bajo costo por tenant para soportar una gran cantidad de cuentas pequeñas. * Incorporación rápida de nuevos tenants. * Aislamiento suficiente para la etapa actual, con margen para reforzarlo más adelante. **Modo recomendado: `SCHEMA`** FinX corre en modo `SCHEMA`. Cada tenant obtiene un esquema dedicado dentro de una base de datos PostgreSQL compartida, de modo que: * El costo de infraestructura se mantiene bajo porque los tenants comparten una instancia de base de datos. * Los datos del tenant siguen estando lógicamente aislados — el esquema de un tenant nunca es alcanzable desde el de otro. * La incorporación es ligera, lo que se adapta a una alta tasa de registros de tenants pequeños. El modo `SCHEMA` comparte una instancia de base de datos entre tenants, por lo que el radio de impacto de un incidente a nivel de base de datos es más amplio y el aislamiento de rendimiento es más débil que en el modo `DATABASE`. Planifica migrar los tenants de alto valor o alto volumen a medida que crecen. ### Una ruta de migración a medida que FinX crece Cuando uno de los tenants de FinX se vuelve grande, regulado o sensible al rendimiento, FinX puede migrar ese tenant de modo `SCHEMA` a modo `DATABASE` — sin reemitir tokens ni cambiar la identidad del tenant, porque el aislamiento es una propiedad del *servicio*, no del tenant. Elige el tenant cuyo volumen, perfil de riesgo o necesidades de cumplimiento justifican ahora una base de datos dedicada. La plataforma aprovisiona una nueva base de datos PostgreSQL aislada para el tenant y ejecuta las migraciones, exactamente como en el [aprovisionamiento automático](/es/multi-tenancy/auto-provisioning). Los datos del tenant se mueven desde su esquema en la base de datos compartida hacia la nueva base de datos dedicada. El registro de servicio del tenant se actualiza a la configuración de modo `DATABASE`. El claim `tenantId` no cambia, por lo que las integraciones siguen funcionando sin modificaciones. Comenzar en modo `SCHEMA` y promover tenants individuales a modo `DATABASE` te permite mantener bajos los costos al principio y reservar bases de datos dedicadas para los tenants que realmente las necesitan. ## Páginas relacionadas *** La comparación completa DATABASE vs. SCHEMA y el flujo de migración. Cómo se aprovisiona y migra la infraestructura de un tenant. Por qué el aislamiento es una propiedad del servicio, no del tenant. Garantías de aislamiento y credenciales para ambos modos.