Quan una aplicació SaaS comença a créixer, un dels primers dilemes tècnics és com aïllar les dades de cada client. La tria entre un esquema compartit amb control d'accés per files (RLS) o un esquema separat per inquilí afecta no només el rendiment, sinó també l'estratègia de migracions, còpies de seguretat i compliment normatiu. A Q2BSTUDIO, com a empresa especialitzada en desenvolupament de programari a mida, hem analitzat aquest problema en profunditat per als nostres clients que despleguen solucions al núvol amb AWS o Azure, integren intel·ligència artificial, protegeixen les seves dades amb ciberseguretat avançada i utilitzen eines de BI com Power BI. Aquest article ofereix una anàlisi tècnica i empresarial perquè puguis escollir el model adequat des de l'inici.
El model d'esquema compartit amb Row-Level Security (RLS) és el punt de partida més comú. Consisteix a afegir una columna tenant_id a cada taula i activar polítiques RLS a PostgreSQL que filtrin automàticament les files segons el context de l'inquilí. El principal avantatge és la simplicitat operativa: una sola migració, un únic conjunt d’índexs i la possibilitat de fer consultes creuades entre tots els clients sense complexitat afegida. El pool de connexions funciona de forma natural i l'aïllament es garanteix a nivell de base de dades, no d'aplicació. Per a projectes amb un nombre incert d'inquilins i càrregues homogènies, aquesta aproximació és la més àgil. No obstant, cal anar amb compte: si no es força el RLS amb FORCE ROW LEVEL SECURITY, el propietari de la taula podria eludir les polítiques. També és fonamental establir el context d'inquilí dins d'una transacció usant set_config amb abast local per evitar fuites entre peticions quan s'utilitza PgBouncer en mode transaccional. En els nostres serveis cloud AWS/Azure implementem aquestes pràctiques per garantir la seguretat des del primer dia.
El model d'esquema per inquilí (schema-per-tenant) assigna un esquema PostgreSQL independent a cada client. Les taules són idèntiques en estructura, però les dades estan físicament separades. Això simplifica el codi de l'aplicació, ja que no cal escriure clàusules WHERE tenant_id = ? ni mantenir polítiques RLS. La restauració d'un sol inquilí és trivial: n'hi ha prou amb recuperar l'esquema des d'una còpia de seguretat. A més, es poden afegir columnes o índexs personalitzats sense afectar altres clients, cosa útil en entorns empresarials amb requisits de compliment com el GDPR. No obstant, la complexitat operativa creix ràpidament: cada migració s'ha d'executar a tots els esquemes, cosa que amb desenes de milers d'inquilins es converteix en un problema de planificació. El catàleg de PostgreSQL s'infla amb milers d'objectes, degradant el rendiment del planificador. A més, les consultes transversals entre inquilins requereixen unions explícites o una capa d'agregació externa. Per això, aquest model és adequat quan el nombre de clients és previsible i acotat (desenes o pocs centenars), i quan es necessita un aïllament que el client pugui percebre com “separat”.
Hi ha una tercera opció, la base de dades per inquilí, que ofereix el màxim aïllament físic. Cada client té la seva pròpia base de dades, fins i tot servidor dedicat. Això permet complir requisits de residència de dades (per exemple, emmagatzemar en una regió concreta d'Azure o AWS), fer actualitzacions independents i restaurar sense afectar ningú més. No obstant, la sobrecàrrega operativa és enorme: un pool de connexions per base de dades, migracions orquestrades de forma independent i la impossibilitat de fer consultes SQL entre inquilins. Només recomanem aquest enfocament per a contractes empresarials d'alt valor on el cost no és un factor limitant.
Per ajudar-te a decidir, aquí tens una matriu comparativa:
Criteri – Esquema compartit + RLS / Esquema per inquilí / Base de dades per inquilíNombre d'inquilins: centenars a milions / desenes a pocs milers / desenesComplexitat de migracions: baixa (una sola execució) / mitjana (una per esquema) / alta (per base de dades)Radi d'explosió en cas d'error: alt (tots els inquilins) / mitjà (límit de l'esquema) / baix (una base de dades)Restauració individual: difícil / directa / trivialConsultes transversals: SQL fàcil / feixuc / només per APIRisc de veí sorollós: alt / mitjà / capBaixa per GDPR: DELETE múltiples taules / DROP SCHEMA / DROP DATABASEAïllament físic: no / no / síPool de connexions: simple / requereix cura / complexPersonalització per inquilí: difícil / possible / control total
Quan començar amb esquema compartit i RLS: si estàs desenvolupant un MVP sense conèixer l'evolució del nombre de clients, si tots tenen càrregues similars i necessites analítiques transversals amb facilitat. És l'opció que manté més portes obertes i permet migrar més endavant si cal.
Quan passar a esquema per inquilí: quan el nombre de clients sigui estable i acotat, quan venguis a empreses que exigeixin una separació clara de dades o quan necessitis restaurar un inquilí concret sense complicacions. La migració des d'esquema compartit es pot fer inquilí per inquilí, amb un període de doble escriptura i verificació d'integritat mitjançant comparació de “checksums”. En els nostres projectes de BI amb Power BI sovint recomanem aquest model per garantir la confidencialitat de les dades per client.
Quan optar per base de dades per inquilí: si tens clients empresarials amb contractes que exigeixen residència de dades en regions específiques, o si el producte és una infraestructura on cada client espera recursos dedicats. El cost i la complexitat operativa només es justifiquen en aquests casos.
A Q2BSTUDIO sabem que triar el model d'aïllament adequat des del principi estalvia setmanes de treball posterior. El nostre equip integra aquestes decisions amb solucions de intel·ligència artificial, agents d'IA, ciberseguretat i automatització de processos. Tant si treballes a AWS com a Azure, t'ajudem a dissenyar una arquitectura multi-inquilí que creixi amb tu.
