Supabase som backend för svenska SaaS: Auth, RLS, Edge Functions

För ett svenskt SaaS-bolag i tidig fas är frågan sällan vilken databas som är mäktigast, utan hur snabbt ni kan komma i produktion med något ni vågar lita på. Supabase är ofta mitt förstaval just där: det är Postgres i botten, men med autentisering, radnivå-säkerhet, fillagring och serverlösa funktioner inbyggt. Ni slipper bygga ett helt eget backend-lager innan ni ens har en betalande kund. Den här guiden går igenom de tre delar som avgör om bygget håller: Auth, Row Level Security och Edge Functions.

Auth: identitet som inte blir ett eget projekt

Supabase Auth ger inloggning med e-post, magiska länkar och sociala inloggningar utan att du behöver hantera lösenordshashning eller sessioner själv. Det viktiga för ett B2B-SaaS är att tidigt bestämma hur ni modellerar organisationer. En användare tillhör nästan alltid ett företag, ofta med en roll, och den kopplingen måste finnas i datamodellen från dag ett. Att lägga till multitenancy i efterhand är ett av de dyraste omtagen jag ser.

Varje inloggad användare får ett JWT som bär med sig sitt user-id. Den token är hela grunden för säkerhetsmodellen vi bygger härnäst.

Row Level Security är där säkerheten faktiskt bor

Det här är Supabases starkaste och samtidigt farligaste egenskap. Med RLS flyttar du behörighetsreglerna in i databasen: en policy avgör vilka rader en viss användare får läsa eller ändra. Rätt använt betyder det att även om någon kommer åt din databasnyckel kan de bara se sin egen organisations data. Fel använt - eller bortglömt - betyder det att alla kan se allt.

Min hårda regel: aktivera RLS på varje tabell direkt när den skapas, även innan policys finns. En tabell utan RLS men exponerad mot klienten är en öppen dörr. Skriv sedan policys som utgår från company_id kopplat till den inloggade användaren, och testa dem genom att faktiskt logga in som två olika kunder och försöka nå varandras data. Det är detaljarbetet i RLS som jag oftast bygger tillsammans med kunder inom webbutveckling.

Edge Functions för logik som inte hör hemma i klienten

Det mesta kan ske direkt mot databasen via klientbiblioteket, skyddat av RLS. Men en del får aldrig ligga i klienten: anrop mot Stripe med hemliga nycklar, webhooks från externa tjänster, e-postutskick, eller tunga beräkningar. Det är där Edge Functions kommer in - serverlösa funktioner som körs nära användaren och har tillgång till dina hemligheter på ett säkert sätt.

Ett typiskt mönster: en Edge Function tar emot Stripes webhook när en betalning lyckas, verifierar signaturen, och uppdaterar prenumerationsstatusen i databasen med en behörighet som klienten aldrig ser. Klienten läser sedan bara resultatet via RLS-skyddade tabeller.

Realtime och fillagring - använd det ni behöver

Supabase kan strömma databasändringar i realtid till klienten, vilket är guld för aviseringar och samarbetsfunktioner men onödig komplexitet för en enkel CRUD-app. Samma sak med Storage för filer: utmärkt när ni behöver det, men koppla på det när behovet finns, inte för att det går. Den disciplinen håller arkitekturen begriplig.

När Supabase inte är rätt val

Jag ska vara ärlig: Supabase passar inte allt. Om ni har extrema krav på databasprestanda, behöver finmaskig kontroll över Postgres-konfigurationen, eller redan har en stark plattform i en annan molnleverantör, kan en mer renodlad lösning vara bättre. Och RLS är kraftfullt men har en inlärningskurva - underskatta den inte. För de flesta tidiga och medelstora svenska SaaS-bolag väger fördelarna ändå tungt, vilket jag visar i konkreta uppdrag i kundcase.

Relaterat

• Core Web Vitals 2026: INP-optimering för komplexa React-appar
• Edge runtime patterns: Geolokalisering, A/B-test och AI på kanten
• Headless CMS-jämförelse: Sanity vs Contentful vs Payload vs Strapi

Vill du ta det vidare?

Jag bygger SaaS-backend på Supabase för svenska bolag - med RLS-policys som faktiskt testas och en datamodell som tål att växa. Boka ett samtal så går vi igenom ert use case.