multi-tenant con row-level security: por qué importa para tu privacidad.

"Multi-tenant" (multi-inquilino) describe una arquitectura donde una sola plataforma sirve a muchos clientes distintos sobre la misma infraestructura técnica, en vez de levantar un servidor separado para cada uno. Es el modelo detrás de casi todo el software B2B moderno: tu cuenta de correo, tu CRM, tu plataforma de ecommerce. La alternativa —un servidor dedicado por cliente— es más cara de operar y más difícil de mantener actualizada, así que casi ningún SaaS serio la usa hoy.

El punto delicado del multi-tenant no es técnico, es de confianza: si mi negocio y el de mi competidor usamos la misma plataforma, ¿qué garantiza que mis conversaciones, mis contactos y mi catálogo nunca se mezclen con los suyos?

La forma más común de aislar clientes en un SaaS multi-tenant es que el código de la aplicación agregue, en cada consulta a la base de datos, una condición del tipo "solo trae los datos de este workspace". Funciona la mayoría del tiempo, pero depende de que absolutamente cada consulta, en cada endpoint, en cada versión futura del código, incluya esa condición correctamente. Basta que un desarrollador olvide un filtro en una sola ruta —algo que ha pasado en plataformas grandes y conocidas— para que un cliente vea, aunque sea por unos minutos, datos que no le pertenecen.

Ese riesgo no es hipotético ni exclusivo de heysteff: es el problema central de cualquier arquitectura multi-tenant que confía el aislamiento solo a la disciplina del código de aplicación.

Row-Level Security (RLS) es una función de las bases de datos relacionales modernas —Postgres, la que usa heysteff, entre ellas— que permite definir una regla de acceso directamente sobre una tabla: "esta consulta solo puede ver las filas que pertenecen al workspace actual". La regla vive en la base de datos, no en el código de la aplicación, y se aplica automáticamente en cada consulta sin importar qué parte del sistema la esté ejecutando.

La diferencia práctica es enorme. Con RLS activo, aunque una consulta de aplicación tuviera un error y "olvidara" filtrar por workspace, la base de datos igual bloquea el acceso a filas de otro cliente porque la regla de seguridad no depende de esa consulta: es un requisito impuesto por debajo, a nivel de motor de base de datos. Es la diferencia entre confiar en que todos se acuerden de cerrar la puerta y tener una cerradura que se cierra sola.

No todas las plataformas multi-tenant implementan RLS: agrega complejidad de diseño y exige pensar el modelo de datos desde el principio con el aislamiento en mente, no como un parche posterior. Por eso, cuando un proveedor de software B2B menciona explícitamente Row-Level Security como parte de su arquitectura, es una señal concreta —no un eslogan de marketing— de que el aislamiento entre clientes se tomó en serio desde el diseño de la base de datos, con una capa de defensa adicional a la del código de la aplicación.

En heysteff, cada tabla que guarda datos de un cliente —conversaciones, contactos, credenciales de canales, flujos de automatización— tiene RLS habilitado con reglas de lectura y de escritura. Las operaciones internas de la aplicación corren dentro de ese contexto de aislamiento por workspace; solo procesos administrativos específicos, auditados, pueden operar fuera de él cuando la operación lo exige por naturaleza (por ejemplo, el sistema de facturación).

Si estás evaluando cualquier plataforma SaaS que vaya a manejar datos de tus clientes —no solo heysteff—, vale la pena preguntar directamente: ¿el aislamiento entre clientes depende solo del código de la aplicación, o hay una capa de seguridad impuesta a nivel de base de datos? Es una pregunta técnica, pero la respuesta te dice mucho sobre cuánto se pensó la privacidad desde el diseño, no como un agregado tardío.

• Cómo protege heysteff los datos de tus clientes
• Uptime y transparencia: cómo leer nuestra página de status
• Seguridad en heysteff
• Preguntas frecuentes