Jeg vælger database-hosting som om jeg skal kunne sove søndag nat

De fleste sideprojekter dør ikke på kode, de dør på drift, og Postgres-hosting er et af de steder, hvor man kan få meget ondt i maven meget hurtigt.

1. Hvad du faktisk køber, når du køber Postgres-hosting

Jeg troede længe, at jeg bare “købte en database”. En URL, et password og så afsted.

I praksis køber du tre ting:

1. Drift – nogen holder motoren i gang, patchede, overvågede servere, plads på disken.
2. Grænser – hvor meget CPU, RAM, storage, connections, I/O du må bruge.
3. Redningsnet – backups, point-in-time-restore, logs, metrics, “åh nej jeg slettede en tabel”.

Det er de tre ting, der afgør, om din løsning føles som en hjælp eller som en tikkende bombe.

Drift: hvem er DBA’en i rummet?

Hvis du selv hoster Postgres på en VPS, så er svaret nemt: det er dig. Du er DBA’en.

I managed Postgres på fx Render eller Fly er der en usynlig DBA, som:

• holder Postgres-versionen opdateret
• sørger for, at maskinen genstarter og kommer op igen
• giver dig disk, CPU og RAM i en eller anden pakke

I Supabase og Neon får du både drift og ekstra “lag udenom” databasen: dashboards, auth, storage, branching osv.

Hvis du er typen, der hellere vil kode features end at læse Postgres release notes, så er det her, du betaler dig fra det.

Limits: hvor rammer det dig i hverdagen?

Limits lyder kedeligt, men det er typisk her, projektet begynder at gøre ondt.

De vigtige for Postgres-hosting er:

• Connections – hvor mange samtidige forbindelser du må have
• Storage – hvor mange GB data du må fylde på
• CPU / RAM – hvor mange queries du kan køre, før alt bliver sløvt
• Requests pr. sekund (ofte skjult i pris-modellen)

Især connections bider hårdt. Et klassisk Node-setup uden pooling kan brænde alle dine connections af, selvom du kun har få brugere. Det er også en af de ting, der adskiller fx Supabase vs Neon på de små gratis- og low-tier planer.

Redningsnet: hvor ondt gør en fejl?

Jeg har én regel for databaser: jeg vælger kun løsninger, hvor det er realistisk at rette op på en fejl, jeg selv har lavet.

Det betyder i praksis:

• Automatiske backups uden jeg skal huske det
• Mulighed for at gendanne til et bestemt tidspunkt (point-in-time, PITR)
• Et UI eller CLI til at lave en klon af produktion til test

Hvis du vil dykke mere ned i hvorfor, så har jeg skrevet om hvor lidt man har lyst til at rulle en fejl tilbage uden at have tænkt sig om først.

2. De kriterier du faktisk skal sammenligne Postgres-hosts på

Jeg har efterhånden prøvet de fleste: klassisk managed Postgres, Supabase, Neon, Railway, Render og egne VPS’er.

De samme seks ting går igen hver gang:

1. Pris og skaleringsmodel
2. Backups og restore-muligheder
3. Connection pooling
4. Latency og regions
5. Ekstra features (auth, storage, functions)
6. Vendor lock-in og hvor nemt det er at flytte væk

1. Pris og model: hvad sker der, når du vokser?

“Managed Postgres pris” er et søgeord af en grund: mange opdager først den rigtige pris, når regningen kommer.

Sådan prøver jeg at læse prissider:

• Hvad koster mindste plan med fornuftige grænser?
• Hvad sker der, hvis jeg 10-dobler brugen?
• Er der skjulte ting: I/O, antal branches, antal projekter?

Gratis tiers er fine til legeprojekter, men hvis du vil bygge noget, der kan få rigtige brugere, så kig på den mindste betalte plan. Det er dér, du lander hurtigt, hvis det går bare en lille smule godt.

2. Backups: automatisk eller “du glemte at slå det til”

Backups kan være:

• full-dumps en gang i døgnet
• kontinuerlig WAL-baseret backup med point-in-time-restore

Hvis du kun har daily dumps, kan du tabe en hel dags data, hvis du opdaterer en tabel forkert kl. 22.30.

Jeg kigger altid efter:

• Hvor ofte bliver der taget backup?
• Hvor længe kan jeg gå tilbage?
• Kan jeg selv starte en restore til en ny database uden at skrive til support?

3. Connection pooling: du vil gerne have en voksen i rummet

Postgres er ikke glad for at have 5000 åbne connections. Det bruger masser af RAM og laver context switching.

En connection pool:

• holder en lille håndfuld connections åbne mod Postgres
• fordeler dine requests (fx fra en serverless app) ind over de få connections

Supabase har pgBouncer-lignende pooling bygget ind. Neon har deres egen proxy-lag. Klassisk managed Postgres kræver typisk, at du selv sætter pooling op, eller at din app er meget disciplineret.

4. Latency og regions

Hvis din backend kører i Frankfurt, og din database kører i USA, har du lige foræret dig selv 100 ms ekstra pr. query.

Derfor kigger jeg på:

• Kan jeg vælge region til databasen?
• Matcher det regionerne på min hosting af API eller frontend?
• Er der edge-features, der ændrer mønstret (fx caches)?

Til små projekter er det mest “føles siden snappy” og “går min hosting i samme datacenter-klynge”. Men hvis du vil bygge noget til flere verdensdele, så hører du hjemme i kategorien backend til web med lidt flere ting at tage stilling til.

5. Ekstra features: auth, storage, functions

Supabase sælger sig selv på, at du får et helt “backend as a service”-lag ovenpå Postgres: auth, file storage, edge functions.

Neon går mere benhårdt efter at være “serverless Postgres” med fed udvikleroplevelse (branching).

Managed Postgres hos fx Render, Fly eller DigitalOcean er lidt kedeligere: du får “bare” databasen. Til gengæld er det tit mere gennemsigtigt, hvad du betaler for.

6. Vendor lock-in: kan du flytte om et år?

Postgres som database hjælper dig faktisk her. SQL er SQL, og du kan tage et dump og flytte.

Men:

• Hvis du bruger Supabase-auth hårdt, så er det mere arbejde at flytte
• Hvis du bruger Neons branching i dit workflow, bliver det også en vane
• Din “lock-in” sidder ofte mere i dine vaner og integrationer end i selve data

Derfor plejer jeg at tænke lock-in som et spørgsmål om: “kan jeg fysisk flytte data”, og “hvor meget kode skal jeg skrive om, hvis jeg gør det”.

3. Supabase: hvornår det er en gave, og hvornår det er for meget

Supabase har jeg brugt til flere små og mellemstore ting. Det føles lidt som at få backend-hjul på sin cykel, uden man selv skal finde værktøjet frem.

Hvornår Supabase er genialt

Jeg ville klart overveje Supabase, hvis:

• du bygger en klassisk webapp med brugere, login og lidt filer
• du gerne vil have auth på plads uden at rode med JWT, cookies og alt det selv
• du er okay med at lære deres måde at tænke på (Row Level Security, deres dashboards osv.)

Typisk use case:

• Next.js frontend
• Supabase som database + auth + storage
• SSR eller edge-funktioner med direkte Supabase-klient

Her får du meget for pengene. Specielt til et “bedste database til sideprojekt”-scenarie, hvor du både vil lære noget og have en chance for at få rigtige brugere på.

Hvornår Supabase bliver for tungt

Der er også scenarier, hvor jeg personligt ville holde mig fra det:

• store batch-importer med mange rækker og tunge queries
• ekstremt webhook-tungt setup med mange små kald i sekundet
• noget hvor du gerne vil holde infrastrukturen så klassisk som muligt (fx pga. senere migrering til stor managed Postgres-klynge)

Supabase laver meget smart magi ovenpå Postgres, men det kan også gøre fejlsøgning lidt sværere. Der kan være flere lag at kigge igennem, når noget går galt.

Supabase og pris

På de små planer får du meget, men kig godt på:

• storage-priser, hvis du vil gemme mange filer
• grænser på rækker / båndbredde
• pris-springet til næste plan, hvis du vokser

Jeg har haft et lille hobby-projekt, der var gratis længe, indtil nogle venner virkelig tog appen i brug, og pludselig røg jeg op på en betalt plan. Det var fair nok, men godt jeg lige havde kigget prissiden igennem på forhånd.

4. Neon: serverless Postgres og fede branches

Neon er lidt en anden vinkel. De siger: “vi er din Postgres, resten må du selv bygge”.

Branching: din database får feature-branches

Neon kan lave branches af din database, næsten som git. Det betyder:

• du kan have en “prod”-branch med rigtige data
• du kan lave en “feature-X”-branch, hvor schema og data starter som en kopi
• du kan teste migrationer, nye features, seed-data osv. uden at røre prod

Det her spiller sindssygt godt sammen med et mere seriøst workflow med migrations, CI og testmiljøer, især hvis du er flere på et projekt. Hvis du kigger på artiklen om database-migrationer i teams, så er Neons måde nærmest bygget til den slags.

Serverless og cold starts

Neon skalerer ned, når din database ikke er i brug. Det er fint til sideprojekter, der ikke kører døgnet rundt.

Men det betyder også:

• første request efter stilstand kan være lidt langsommere
• hvis du har mange små, spredte kald (webhooks, cron-jobs, små API-requests), kan du mærke det mere

Jeg plejer at afprøve det i praksis: lad appen stå lidt, prøv at åbne siden igen, og se hvordan det føles. Det er ikke altid et problem, men jeg vil gerne have oplevet det, før jeg beslutter mig.

Typiske begrænsninger hos Neon

På de små planer er det især:

• storage-grænser
• antal branches
• antal forbindelser (igen: pooling er din ven)

Til gengæld er Neon meget “ren” Postgres. Du får ikke auth, fil-storage osv. Du parrer det ofte med din egen backend i fx Node eller Python og bygger det hele mere klassisk.

5. Render, Fly og klassisk managed Postgres: den kedelige løsning, der ofte holder længst

Jeg har en svaghed for kedelige løsninger. De er tit dem, der overlever.

En klassisk managed Postgres-instans (Render, Fly, DigitalOcean, andre) giver dig:

• en fast maskine (virtuel) med Postgres installeret
• tydelige grænser: X CPU, Y RAM, Z GB disk
• ofte fornuftige backups og metrics

Hvornår jeg går “klassisk”

Jeg ender med den her type hosting når:

• jeg ved, at der kommer en del trafik (lille SaaS med betalende kunder)
• vi er flere udviklere, og vi vil have simpel, gennemskuelig infrastruktur
• vi vil kunne tage databasen og flytte til en anden udbyder uden at pille alt kode fra hinanden

Her er der ikke noget hokus pokus. Du får en connection-string, du kører dine migrations, og så kører det.

Hvad du skal holde øje med i “managed Postgres pris”

• Hvor nemt det er at opgradere instansen (CPU/RAM/GB) uden downtime
• Hvad backups og PITR koster
• Om storage og compute skaleres sammen eller hver for sig

Det føles måske mere som rigtig deployment og drift end Supabase gør, men det er også her, du lærer noget om, hvordan et produktions-setup typisk ser ud i virkeligheden.

6. Beslutningsmatrix: fem konkrete scenarier og mit valg

Teori er fint, men jeg vælger næsten altid ud fra konkrete projekter. Her er fem klassiske, jeg selv eller venner har haft.

Scenario 1: Portfolio-app med login og lidt data

Fx: en lille side, hvor du viser projekter, måske et lille admin-login, lidt brugerdata, men ikke massiv trafik.

Jeg ville typisk vælge:

• Supabase på en gratis eller lille betalt plan

Grunde:

• du får auth uden at bruge en weekend på det
• du lærer at bruge et moderne backend-værktøj
• Postgres under motorhjelmen, så du stadig lærer “rigtig” database

Scenario 2: Lille SaaS med betalende kunder

Her bliver jeg straks mere konservativ. Penge og kundedata gør altid alt en tak mere alvorligt.

Jeg ville overveje to veje:

• Supabase, hvis jeg vil have hurtig time-to-market og kan leve med deres prisstruktur
• Managed Postgres (Render/Fly/DigitalOcean), hvis jeg vil have mere kontrol og en ren database uden ekstra lag

Hvis du allerede har erfaring med databases og vil have et “kedsommeligt, stabilt” setup, så hælder jeg selv mod managed Postgres her.

Scenario 3: Webhook-heavy app der modtager mange små kald

Fx en app, der tager imod mange webhooks pr. minut fra betalingsudbydere, e-handelsplatforme eller lignende.

Her er vigtige ting:

• connection pooling og god håndtering af spikes
• mulighed for at skrive events hurtigt ind uden at trigge alt for meget compute

Mit valg:

• Neon eller klassisk managed Postgres, koblet til en simpel backend, der kan håndtere retries og idempotens

Jeg ville prøve at holde infrastrukturen så simpel som muligt: én database, én API-service, god logging og fokus på at undgå dobbelt-skrivninger.

Scenario 4: Dataimport og analyse, få brugere, meget data

Fx en app, der importerer CSV eller API-data og giver dig dashboards. Ikke mange samtidige brugere, men store tabeller.

Her er billig storage og fornuftige I/O-grænser vigtige.

Mit valg:

• Managed Postgres hos en udbyder, hvor storage er relativt billigt

Fordelen er, at du ofte kan opgradere disken uden nødvendigvis at skulle 10-doble CPU’en.

Scenario 5: Studie- eller teamprojekt med fokus på læring

Fx et projekt på studiet eller et internt værktøj, hvor I er flere, der bygger sammen og gerne vil lære “rigtig backend”.

Her ville jeg ærligt nok designe efter, hvad I vil lære:

• Supabase, hvis I vil prøve moderne BaaS
• Neon, hvis I vil eksperimentere med branching og CI
• Managed Postgres, hvis I vil øve jer på et klassisk produktionssetup

Hvis det også skal på CV’et, giver det mening at vælge noget, man kan fortælle om i en ansøgning, fx hvordan I har sat migrations og miljøer op. Det spiller godt sammen med kategorierne om full stack workflows og samarbejde i kodeprojekter.

7. Sådan passer database-hosting ind i dit migrations- og CI-flow

Database-valget er ikke kun pris og features. Det påvirker også, hvordan du arbejder i hverdagen.

Migrations: ét sandhedspunkt for schema

Uanset host vil jeg have:

• et migrations-værktøj (fx Prisma, Drizzle, Flyway, knex-migrations)
• migrations-versioner i git
• samme migrations kørt i dev, staging og prod

Det gælder især, hvis I er flere på projektet. Ellers rammer I hurtigt den klassiske “det virker på min maskine”-situations, som jeg har skrevet om i artiklen om database-migrationer i teams.

CI: test dine migrations og queries, før du deployer

Et typisk CI-flow for et Postgres-projekt:

1. Spind en midlertidig database op (lokalt eller via din host)
2. Kør alle migrations
3. Kør tests, der rammer databasen (integrationstests)

Her er Neon ret sjov, fordi du kan lave en branch per CI-job. Supabase og managed Postgres kræver typisk, at du selv opretter en test-database, men princippet er det samme.

Miljøer: dev, staging, prod

Jeg prøver altid at have mindst to miljøer:

• dev – må gerne blive slettet, brugers til leg og lokal udvikling
• prod – hellig, med rigtige data og skrappe regler

Hvis jeg har energi til det, lægger jeg en staging ind i midten, der ofte er en kopi af prod-data med anonymisering.

Din Postgres-host skal gøre det nemt at:

• oprette nye databaser (projekter/branches)
• gøre dem rene (nulstille, droppe, genskabe)
• dele credentials sikkert mellem team-medlemmer

8. Exit-plan: sådan vælger du Postgres uden at få weekend-mareridt senere

Det, der ofte holder folk tilbage fra Supabase eller Neon, er frygten for at sidde fast. Det kan jeg godt forstå.

Jeg plejer at tænke exit-plan allerede, når jeg vælger host. Ikke fordi jeg nødvendigvis vil flytte, men fordi det gør mig roligere at vide, at jeg kan.

Trin 1: Hold dig til almindelig Postgres og SQL

Uanset host kan du gøre livet lettere for fremtidige dig ved at:

• bruge almindelige Postgres-features, ikke meget eksotiske extension-kombinationer
• skrive SQL der også kører på andre Postgres-versioner
• undgå at bygge for meget logik ind i host-specifikke features, medmindre du ved, du bliver der længe

Trin 2: Øv dig på at tage backup og restore tidligt

Lav en øvelse tidligt i projektet:

1. Eksporter databasen (dump)
2. Opret en ny database et andet sted (lokalt eller hos en anden host)
3. Importer dumpet
4. Kør din app mod den nye database

Det er lidt kedeligt, men når du har gjort det én gang, er det ikke længere et mystisk monster, men bare en tjekliste.

Trin 3: Dokumentér dine afhængigheder

Skriv ned i din README:

• Hvilken Postgres-version du forventer
• Hvilke extensions du bruger
• Om du bruger host-specifikke features (Supabase auth, Neon-branching osv.)

Det gør det meget nemmere at vurdere en flytning senere. Og hvis du en dag sidder til et kodeinterview, er det faktisk rart at kunne pege på, at du har tænkt over sådan noget, ikke kun skrevet endpoints. Det ligger i samme familie som at kunne overleve git uden at kende hele værktøjet.

Trin 4: Design dine secrets og connection-strings rigtigt

Brug miljøvariabler til alt, hvad der har med database-forbindelsen at gøre:

DATABASE_URL=postgres://user:password@host:5432/dbname

Og sørg for, at din kode aldrig har host-navn eller credentials hardcodet. Så bliver det at flytte host næsten kun et spørgsmål om at ændre miljøvariablerne.

Hvis du i forvejen arbejder med miljøvariabler og synes, det føles lidt som magi, er der en artikel om at gemme API-nøgler det rigtige sted, der også rammer databaser ret godt.

9. Så hvad ville jeg selv gøre i dag?

Jeg er blevet mere fejlforskrækket med årene. Til små ting hvor jeg vil bygge hurtigt, tager jeg Supabase eller Neon, fordi jeg gerne vil have lidt luksus og gode dashboards.

Til alt, hvor andre mennesker lægger deres data eller penge i mine hænder, ender jeg oftest på kedelig managed Postgres, netop fordi det er kedeligt. Det er lidt det samme som altid at have surdej i køleskabet: det kræver lidt disciplin, men det betaler sig over tid.