Multitenant

Multitenant (multiinquilino) es un modelo de arquitectura de software en la nube donde una única instancia del sistema, corriendo sobre infraestructura compartida, atiende a muchos clientes a la vez. A cada cliente se lo llama tenant (inquilino), y aunque todos usan el mismo código y la misma base de datos, los datos de cada uno quedan aislados de forma lógica: nadie ve la información del otro. Es el patrón que hace posible el modelo SaaS (software como servicio) tal como lo conocemos.

La analogía clásica es la de un edificio de departamentos: todos los inquilinos comparten la estructura, la cañería y el ascensor (la infraestructura), pero cada uno tiene su propio departamento con llave (sus datos privados). Lo opuesto es el modelo single-tenant, donde cada cliente recibe su propia instancia dedicada, como una casa individual.

Salesforce fue una de las plataformas pioneras en llevar esta arquitectura al CRM empresarial: cada empresa trabaja en su propia org, pero por debajo comparte el mismo núcleo de software que el resto de los clientes del mundo, lo que permite que todos reciban las actualizaciones automáticas tres veces al año sin instalar nada.

El concepto de multitenant resuelve un problema económico antes que técnico. Mantener una instalación de software dedicada por cliente (servidores, parches, actualizaciones, monitoreo) es caro y no escala. Al compartir una única base de código y una infraestructura común entre miles de clientes, el proveedor reparte ese costo y puede ofrecer el servicio por una suscripción mensual accesible. Esa eficiencia de costos es, en gran medida, lo que hizo viable la explosión del SaaS en los últimos veinte años.

Cómo se aísla la información

La pregunta obvia de cualquier responsable de IT es: si todos comparten la misma base de datos, ¿cómo se garantiza que mis datos no se mezclen con los de otra empresa? La respuesta es el aislamiento lógico. En el modelo de Salesforce, cada fila de cada tabla lleva un identificador de organización (un OrgID) que actúa como una etiqueta invisible. El motor de la plataforma agrega de manera automática y obligatoria un filtro por ese identificador a cada consulta, de modo que una empresa nunca puede leer ni alcanzar registros de otra. El aislamiento no depende de la buena voluntad del desarrollador: está cableado en el núcleo de la plataforma.

Las tres variantes habituales

No todas las arquitecturas multitenant aíslan los datos de la misma forma. En la práctica conviven tres enfoques, con distinto balance entre eficiencia y aislamiento:

• Base de datos compartida con esquema compartido: todos los tenants viven en las mismas tablas y se separan por una columna identificadora (el modelo de Salesforce). Es el más eficiente en costo y el que mejor escala.
• Base de datos compartida con esquemas separados: una sola base de datos, pero cada tenant tiene su propio conjunto de tablas. Más aislamiento, algo menos de eficiencia.
• Base de datos separada por tenant: cada cliente tiene su propia base. Es lo más cercano al single-tenant; máximo aislamiento, pero más caro de operar.

Multitenant vs. single-tenant

Por qué le importa al negocio, no solo a IT

Para un comité de compra que evalúa una plataforma como Salesforce, lo multitenant tiene consecuencias muy concretas. Primero, nunca quedás atrasado: las tres releases anuales llegan a todos al mismo tiempo, sin proyectos de actualización ni ventanas de mantenimiento propias. Segundo, pagás por uso real vía suscripción, en lugar de invertir por adelantado en licencias e infraestructura. Tercero, la seguridad y el cumplimiento (certificaciones, parches de vulnerabilidades) los gestiona el proveedor para todos a la vez, un nivel de inversión que una sola empresa rara vez podría costear por su cuenta.

El contrapeso son los límites compartidos. Como muchos clientes usan la misma infraestructura, la plataforma impone topes de consumo para que ningún tenant degrade la experiencia de los demás: en Salesforce eso se materializa en los governor limits, reglas que acotan cuántos registros procesa una operación o cuántas consultas hace una transacción.

Un ejemplo concreto en Argentina

Pensá en una distribuidora de Consumo Masivo con sede en Córdoba que adopta Salesforce para su fuerza de ventas. Comparte la misma plataforma con miles de empresas de todo el mundo, pero sus datos de clientes, pedidos y precios viven aislados en su propia org. Cuando llega la release de primavera, su equipo amanece con funciones nuevas de Sales Cloud sin haber tocado un servidor. Y si un desarrollador escribe una automatización que intenta procesar 60.000 registros de una sola vez, la plataforma la frena por los governor limits, protegiendo tanto a esa distribuidora como al resto de los inquilinos.

Errores comunes al razonar sobre multitenant

Un malentendido frecuente es creer que "compartir base de datos" significa "datos menos seguros". En arquitecturas serias ocurre lo contrario: el aislamiento está más controlado y auditado que en muchas instalaciones a medida. Otro error es asumir que multitenant implica cero personalización. Salesforce lo resuelve con un modelo basado en metadatos: cada org define sus campos, objetos y reglas como configuración, no como cambios al código compartido, de modo que cada empresa siente la plataforma como propia sin romper el núcleo común. Confundir esa personalización por configuración con desarrollo a medida lleva a malas decisiones de arquitectura.