Bygg dataprodukter billigt på ett delat register
Ett vanligt samtal: en kund eller partner vill ha åtkomst till en del av din data. Första reflexen är att bygga något eget, som en ny databas för just den kunden, en pipeline som håller den i synk och kanske en liten tjänst framför alltihop. Efter några kunder kostar underhållet mer än datan är värd.
Det finns ett billigare mönster. Ett delat register. En uppsättning policyer för radnivåsäkerhet (RLS). En enda sanningskälla. Varje kund ser bara sin del. Du underhåller en sak.
Därför blir infrastruktur per kund dyrt
Kalkylen ser snabbt dyster ut.
| Kunder | Databaser | Pipelines | Säkerhetskopior | Granskningsloggar |
|---|---|---|---|---|
| 1 | 1 | 1 | 1 | 1 |
| 5 | 5 | 5 | 5 | 5 |
| 20 | 20 | 20 | 20 | 20 |
Varje rad i tabellen är en återkommande kostnad. Utvecklartimmar för att hålla alla pipelines i takt. Lagring. Tidsfönster för säkerhetskopiering. Granskningar av regelefterlevnad. Fem gånger ”fixa migreringen” i stället för en.
Kunden behöver ingen egen databas, bara filtrerad åtkomst till din data.
Så ser ett delat register ut
Fyra delar:
- En registertabell med all referensdata.
- En identitet för den som läser (användare, API-nyckel eller token) som anger vilken kund eller partner det är.
- En RLS-policy som filtrerar raderna utifrån den identiteten.
- Ett API som ger åtkomst till registret. Policyn gäller automatiskt, så ingen ser mer än sin egen del.
Kunden upplever datan som sin egen. Du underhåller en enda databas.
Här passar mönstret
- Referensdata som produkt. En noga sammanställd lista med länder, valutor, taxonomier och branschkoder. Låt prisnivån styra hur mycket som syns: gratiskunder ser namnen, betalande kunder ser koder och metadata, och enterprise-kunder ser hela listan, även de ovanliga posterna.
- Partnerportaler. Varje partner ser sina egna leveranser eller affärer. En integration. Ett API.
- SaaS med flera nivåer. Samma produkt, men vilka rader eller kolumner som syns beror på planen. En annan plan är bara en annan policy.
- Interna avdelningar som kunder. Marknad och ekonomi läser båda kundlistan men ser olika attribut.
En grov kostnadsjämförelse
| Post | Infrastruktur per kund | Delat register + RLS |
|---|---|---|
| Lagring | Växer linjärt | Konstant |
| Pipelines | Växer linjärt | En |
| Ansluta en ny kund | Dagar till veckor | Minuter |
| Schemaändring | En gång per kund | En gång |
| Rätta fel i datan | En gång per kund | En gång |
| Spårbarhet | Utspridd | På ett ställe |
Det delade mönstret vinner på varje rad, så länge kunderna kan leva med filtrerad åtkomst.
När det inte fungerar
- Schemat skiljer sig mellan kunderna. Då handlar det om multi-tenancy, inte RLS.
- Strikta krav på var datan lagras. En kund vars data fysiskt måste ligga i en viss region behöver regionala databaser.
- Kunden ska skriva data. RLS styr läsning. Skrivningar kräver egna policyer och betyder ofta att varje kund får egen data att hålla reda på. Då försvagas den delade modellen.
- Krav på fysisk separation som går att bevisa. Vissa reglerade branscher kräver att datan hålls isär på riktigt, inte med policyer.
Gäller inget av det här är det delade mönstret nästan alltid rätt val.
Checklista: det minsta som behövs
- En registertabell där varje rad som ska filtreras har en kolumn
customer_id(ellertenant_id). - API-nycklar eller tokens som talar om vilken kund det är.
- En RLS-policy på registret som jämför radens
customer_idmed anroparens identitet. - Ett API framför registret. Policyn gäller automatiskt.
- Ett sätt för kunden att se vad som ingår (en metadata-endpoint eller en dokumenterad dataordlista).
- Om du vill: en granskningslogg över vem som har läst vad. Bra att ha, men inte alltid nödvändig.
Det är precis det här RLS-registren i gridmap är byggda för. Behörigheterna kan ligga i gridmap eller synkas från en tabell i datalagret där team- eller kundmodellen redan finns. Lookup API framför registret tillämpar policyn vid varje läsning. En ny kund kräver en ny API-nyckel, inte ny infrastruktur.
Vanliga frågor
Märker kunden att vyn är filtrerad? Bara om du berättar det. RLS syns inte för den som anropar. Det enda vanliga tecknet är att en fråga ger noll rader.
Hur prissätter vi det här? Låt policyn styra prisnivåerna, inte databasen. Det är vilka rader eller kolumner kunden ser som avgör priset, inte hur mycket lagring som går åt.
Vad gör vi om en kund behöver skriva data? Lägg till en liten tabell som kunden får skriva i, med kunden som nyckel. Det delade registret hålls rent, och det som är unikt för varje kund hamnar i ett tunt lager ovanpå.
Poängen med mönstret är att kostnaden per kund ska gå mot noll. Då blir ”ska vi dela den här datan med den här kunden?” ett produktbeslut, inte ett tekniskt.