Estás construyendo un producto para empresas. ¿Cómo aíslas los datos de un cliente de los de otro?

Las tres opciones son un esquema compartido con una columna de id de inquilino, un esquema por inquilino y una base de datos por inquilino, cambiando simplicidad operativa por aislamiento. El esquema compartido escala mejor y cuesta menos, pero exige que el filtro de inquilino se aplique de forma estructural, por ejemplo con seguridad a nivel de fila o una capa de datos que siempre lo añada. Una base de datos por inquilino da el aislamiento más fuerte y la restauración por cliente más sencilla, con un coste operativo real.

Mi opción por defecto es un esquema compartido con un id de inquilino en cada tabla, porque es lo más barato de operar y dar de alta a un cliente es un insert en vez de un proceso de aprovisionamiento. El peligro es obvio, una cláusula where que falte filtra datos entre clientes, así que nunca lo dejo a la disciplina. Uso seguridad a nivel de fila con el inquilino tomado de la sesión autenticada, de modo que incluso una consulta escrita a mano no devuelve nada fuera del inquilino, y añado tests que intentan a propósito leer filas de otro. Paso a un esquema o una base de datos por inquilino cuando hay un motivo real: un cliente con requisitos contractuales de residencia de datos, un puñado de cuentas enterprise lo bastante grandes como para ser su propia carga, o un régimen de cumplimiento que quiere separación demostrable. Los costes son los que la gente subestima: una migración pasa a correr sobre cada esquema, el pooling de conexiones se complica y necesitas automatizar el aprovisionamiento y la restauración por inquilino. También he tenido que resolver aparte a los vecinos ruidosos, con límites de tasa por inquilino, porque aislar datos no es aislar capacidad.