Ordbog
RLS — Row Level Security
En databasepolitik der sikrer, at hver forespørgsel kun ser de rækker den må — typisk scoped til en organisation eller bruger.
Hvad betyder det?
RLS (Row Level Security) er en Postgres-funktion der filtrerer rækker automatisk ud fra politikker I definerer. Applikationen behøver ikke huske `WHERE org_id = …` i hver eneste query — databasen håndhæver det.
I multi-tenant SaaS er RLS ofte den sidste forsvarslinje: selv hvis en bug glemmer et filter i koden, slipper kunde A’s data ikke ud til kunde B.
Hvornår det betyder noget
Multi-tenant produkter
Når flere organisationer deler samme database, og isolation ikke må være valgfri.
Kundeportaler
Når eksterne brugere ser ordrer, dokumenter eller tickets — og fejl er dyre.
Compliance og due diligence
Når I skal kunne forklare hvordan data er isoleret — ikke bare stole på app-kode.
Team der vokser
Når flere udviklere rører queries, og manuelle WHERE-filtre bliver en risiko.
Korte svar
Er RLS det samme som roller i appen?
Nej. App-roller styrer hvad UI’en tillader. RLS styrer hvad databasen overhovedet returnerer — også hvis koden fejler.
Kan vi starte uden RLS?
Til en tidlig prototype med få brugere: nogle gange. Før I har betalende kunder med følsomme data: nej — det er dyrere at skære ind senere.
Virker det kun i Postgres?
RLS som begreb er stærkest i Postgres. Andre databaser har lignende mønstre, men vi bygger typisk på Postgres + RLS.
Læs videre
Læs videre
Dybdegående guides om multi-tenant og portaler.
- SaaS5 minutters læsning
Multi-tenant arkitektur: hvornår, hvordan — og hvad I kan vente med
Multi-tenant lyder som noget man skal beslutte på dag ét. I praksis er det en skala af valg — fra "alle i samme database med et org-id" til fuld isolation. Her er hvordan vi vælger uden at overengineere MVP'en.
→Multi-tenant arkitektur: hvornår, hvordan — og hvad I kan vente med - Web6 minutters læsning
Hvornår har I brug for en kundeportal — og hvornår er et værktøj nok?
De fleste B2B-virksomheder ender med at bygge noget der ligner en kundeportal. Spørgsmålet er om I skal bygge den, eller om et standardværktøj allerede gør jobbet. Her er rammen vi bruger.
→Hvornår har I brug for en kundeportal — og hvornår er et værktøj nok? - SaaS3 minutters læsning
SaaS MVP: hvad hører hjemme i v1 — og hvad venter
Det sværeste ved et MVP er ikke at bygge features — det er at lade være. v1 skal bevise at nogen vil bruge produktet, ikke at I har bygget en mini-enterprise-platform.
→SaaS MVP: hvad hører hjemme i v1 — og hvad venter
Skal jeres data være isoleret rigtigt?
Lad os gennemgå jeres tenant-model.
Vi kigger på queries, politikker og risici — uden at sælge jer unødvendig kompleksitet.