Qué es multi-tenancy:una base de datos, 1.000 clientes

Qué es multi-tenancy: varios clientes comparten una misma base de datos, pero cada cliente solo puede ver sus propios datos. Así es como un fundador en solitario atiende a 1.000 organizaciones desde una única aplicación sin reconstruir nada, y funciona gracias a una columna que debe estar en cada tabla desde el primer día: organization_id.

Si estás construyendo un SaaS con IA, esta es una de las pocas decisiones de arquitectura que no puedes corregir barato más tarde. Aquí tienes qué es multi-tenancy, por qué equivocarse cuesta meses y las reglas exactas que debes darle a tu IA para que lo haga bien.

Qué es multi-tenancy: la analogía del edificio de apartamentos

Piensa en tu SaaS como en un edificio. Cada cliente es un inquilino. Tienes dos opciones.

Podrías construir una casa distinta para cada cliente. Cada casa necesita sus propios cimientos, su fontanería y su mantenimiento. Diez clientes, diez casas. Mil clientes, mil casas, y cuando quieras renovar la cocina, reformarás mil cocinas.

O construyes un único edificio de apartamentos. Unos cimientos, una fontanería, un equipo de mantenimiento. Cada inquilino tiene su propio apartamento, su propia cerradura, su propia llave. Nadie puede entrar en el piso de su vecino, pero tú solo mantienes un edificio.

Multi-tenancy es el edificio de apartamentos. Una aplicación, una base de datos, un despliegue, que sirve a todos los clientes y en el que cada uno ve únicamente sus propios datos. Es la arquitectura estándar de casi todos los productos SaaS que usas, y es lo que hace posible la economía de un SaaS a escala de una sola persona.

Las tres formas de atender a 1.000 clientes

Técnicamente hay tres enfoques. Solo uno tiene sentido para un fundador en solitario:

La tercera opción es en la que ha convergido el sector, y es de lo que trata este artículo. Una base de datos que mantener. Un solo cambio que ejecutar cuando mejoras algo. Una copia de seguridad. Y puedes pasar de 1 a 10.000 clientes sin cambios de esquema.

La columna que necesita toda tabla

Esta es la regla de oro: toda tabla que almacene datos de clientes debe tener una columna organization_id. No "debería tenerla". No "puedes añadirla luego". Debe tenerla, desde el primer día.

No necesitas escribir código para entenderlo. Conceptualmente, cada fila de tu base de datos recibe una etiqueta que dice a qué cliente pertenece. En la tabla de tareas de un gestor de tareas, "Diseñar la página de inicio" lleva la etiqueta de Acme; "Revisar las cifras del T3" lleva la de TechStart. Cada vez que la aplicación lee datos, pide solo las filas con la etiqueta del cliente actual. Cada vez que escribe datos, marca la fila nueva con esa etiqueta. Acme ve las tareas de Acme. TechStart ve las de TechStart. La etiqueta es la llave del apartamento.

Esto parece tedioso. También es el cimiento que hace que todo lo demás funcione, incluida la capa de seguridad que lo aplica automáticamente a nivel de base de datos, que merece (y tiene) su propio artículo.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

"Pero ahora mismo solo tengo un cliente"

Lo oigo constantemente. Esta es la película que se proyecta cuando te saltas multi-tenancy:

• Día 1: construyes para un cliente. Todo funciona. No hacen falta etiquetas: todos los datos son suyos de todos modos.
• Día 30: consigues un segundo cliente. Ahora ambos ven los datos del otro. Pánico. Añadir la etiqueta a cada tabla a posteriori supone unas tres semanas de trabajo, tiempo de inactividad en producción y clientes enfadados.
• La película alternativa: construyes con organization_id desde el día 1. El día 30, el segundo cliente simplemente funciona. El día 300 tienes 100 clientes y no has hecho ningún cambio en la base de datos.

Un amigo mío construyó su SaaS sin multi-tenancy. Cuando llegó a su décimo cliente, pasó tres meses reconstruyendo toda su base de datos. Tres meses sin funcionalidades nuevas mientras los clientes esperaban. No seas esa persona.

Por eso también insisto tanto en diseñar la base de datos antes de escribir prompts: las decisiones que son baratas el primer día (una columna, un hábito) se vuelven brutalmente caras el día 300.

Las tres reglas que lo mantienen rápido y seguro

Regla 1: etiqueta cada tabla, sin excepciones. En el momento en que a una tabla le falta organization_id, esa tabla es una fuga de datos a la espera de producirse. Cuando le des instrucciones a tu IA, conviértelo en una instrucción permanente, no en una petición por tarea: es exactamente el tipo de regla que pertenece a tus decisiones de nivel arquitecto, porque la IA se la saltará encantada si no insistes.

Regla 2: indexa la etiqueta. Un índice es la guía telefónica de la base de datos: le permite saltar directamente a las filas de un cliente en lugar de leer cada fila para comprobar la etiqueta. La diferencia no es teórica: con 1 millón de filas repartidas entre 1.000 organizaciones, una búsqueda sin índice tarda unos 2.000 milisegundos. Con índice, la misma búsqueda tarda unos 5. Pídele a tu IA que añada un índice sobre organization_id en cada tabla que cree.

Regla 3: nunca confíes en el navegador para saber quién pregunta. La identidad del cliente debe salir de la sesión de inicio de sesión en el servidor, nunca de algo que envíe el navegador. Si un usuario malicioso puede decirle a tu app "soy la organización X", puede leer los datos de la organización X. El servidor sabe quién ha iniciado sesión; esa es la única fuente de verdad.

Tres reglas. Una columna. Esa es la diferencia entre una demo y un producto que puedes vender a tu segundo, décimo y milésimo cliente.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Qué significa multi-tenancy en términos sencillos?

Varios clientes (inquilinos) comparten una aplicación y una base de datos, pero cada uno solo puede ver sus propios datos. Como un edificio de apartamentos: una estructura, muchos apartamentos privados, una llave por inquilino. Es la arquitectura estándar de los productos SaaS.

¿Necesito multi-tenancy si solo tengo un cliente?

Sí, y es justo entonces cuando sale barato. Añadir una columna organization_id el primer día no te cuesta nada. Añadirla después de que llegue el cliente dos cuesta semanas; un fundador que conozco pasó tres meses reconstruyendo con el cliente diez. Constrúyelo desde la primera tabla.

¿Puede la IA configurar multi-tenancy por mí si no sé programar?

Sí, si le das la regla de forma explícita: "toda tabla que almacene datos de clientes debe tener una columna organization_id, con un índice, y toda consulta debe filtrar por ella". Las herramientas de IA siguen este patrón de forma fiable cuando se les indica, y lo omiten de forma impredecible cuando no. Tú pones la regla; la IA pone la implementación.

¿Es lo bastante seguro una base de datos compartida para los datos de los clientes?

Sí, cuando se hace bien. La etiqueta organization_id junto con la seguridad a nivel de base de datos (la seguridad a nivel de fila, que aplica la etiqueta automáticamente en cada consulta) es como prácticamente todo el SaaS moderno gestiona el aislamiento; el mismo enfoque sirve a productos con miles de organizaciones. La opción insegura es la versión a medias: base de datos compartida, sin etiquetas, sin aplicación de la regla.