5 señales de que su producto SaaS necesita una arquitectura multiinquilino real

La mayoría de los productos SaaS empiezan con un modelo de datos que técnicamente admite varios clientes pero no fue diseñado para eso: una única base de datos compartida con una columna customer_id añadida después. Eso funciona bien hasta que deja de funcionar, y ese momento suele llegar en el peor momento posible: durante un ciclo de ventas empresarial.

La primera señal es que un prospecto pregunte por las garantías de aislamiento de datos durante la revisión de compras. La segunda es que un ingeniero tenga que escribir un script puntual para corregir datos que se filtraron entre los límites de los inquilinos. La tercera es que el rendimiento de las consultas se degrade de forma impredecible a medida que crece el volumen de datos de su cliente más grande y empieza a afectar a todos los demás en las mismas tablas.

La cuarta señal es necesitar configuración por cliente, feature flags, campos personalizados, políticas de retención distintas, y darse cuenta de que el esquema actual no tiene un lugar limpio dónde ponerlo. La quinta es que un cliente pida un entorno dedicado o garantías de cumplimiento específicas que su arquitectura no puede ofrecer de forma limpia.

La seguridad a nivel de fila, aplicada en la capa de base de datos y no solo en el código de la aplicación, es lo que realmente cierra la brecha de aislamiento. Una convención a nivel de aplicación de "siempre filtrar por tenant_id" funciona hasta que una consulta en algún lugar se olvida de hacerlo, y ese único descuido es el incidente que termina en una revisión de seguridad. Las políticas de seguridad a nivel de fila de Postgres (o el equivalente en su base de datos) hacen que el límite de aislamiento sea algo que la base de datos aplica incluso cuando el código de la aplicación tiene un error.

Probar el aislamiento tiene que ser adversarial, no solo funcional. No basta con verificar que el inquilino A ve los datos del inquilino A; se necesitan pruebas que intenten activamente hacer que el inquilino A vea los datos del inquilino B a través de cada ruta de código, incluyendo tareas en segundo plano, capas de caché e índices de búsqueda, que son los lugares donde realmente se esconden los errores de aislamiento.

La migración en sí es más un problema de secuenciación que de ingeniería. Normalmente empezamos con las tablas de mayor riesgo (las que ya muestran síntomas de rendimiento o fugas), añadimos indexación consciente del inquilino y políticas de seguridad a nivel de fila detrás de un feature flag, validamos contra tráfico de producción en modo sombra, y luego migramos tabla por tabla en lugar de en una sola versión.

Ninguna de estas señales implica una reconstrucción completa. La arquitectura multiinquilino real suele ser una migración incremental: seguridad a nivel de fila, indexación consciente del inquilino y un límite de aislamiento claro, hecha por fases detrás del producto que sus clientes ya usan. La versión costosa es la que se hace bajo presión, durante un trato, en lugar de antes de uno.