Den bedste VPS til selvhostet Supabase i 2026

Selvhosting af Supabase betyder at køre omkring femten Docker-containere, ikke én applikation. PostgreSQL, GoTrue til godkendelse, PostgREST til API'en, Realtime til WebSocket-abonnementer, Storage, Kong som gateway, Studio til dashboardet, plus supporttjenester. Det er en platform, og størrelsen følger af det.

Derfor spænder vejledningen, du vil se, fra "2 GB fungerer" til "16 GB minimum" – begge dele er sande for forskellige implementeringer:

• 2 GB og 1–2 vCPU'er kører en udviklingsinstans eller en engangsstaginginstans. Det vil fungere, og det vil føles stramt.
• 4 GB og 2 vCPU'er er det realistiske produktionsgulv. PostgreSQL alene skal bruge 1-2 GB, før de andre fjorten containere starter.
• 8–16 GB er hvor en produktionsapp med reel trafik hører hjemme, med plads til at databasen kan vokse ind i hukommelsen.
• Disk I/O er vigtigere end CPU. Supabase er Postgres nedenunder, og dårlig IOPS viser sig direkte som langsomme API-svar.

Hurtig sammenligning

Dimensionering af en stak med femten containere

De enkelte tjenester er for det meste beskedne. Problemet er, at der er mange af dem, og en af ​​dem er en database.

Hvorfor 2 GB fejler i produktion. PostgreSQL skal bruge 1-2 GB alene for at holde et brugbart arbejdssæt i delte buffere. Tilføj GoTrue, PostgREST, Realtime, Storage, Kong, Studio og resten, plus operativsystem- og Docker-overhead, og en 2 GB-boks kører alt uden noget ekstra. Den virker, indtil trafikken ankommer, så begynder Postgres at bruge disken til alt, og hele API'en bliver langsommere på én gang.

Lagerpladsen vokser i tre retninger. Basisinstallationen er omkring 10 GB. Derefter dine faktiske data, så logfiler, så sikkerhedskopier. Det er fornuftigt at starte ved 80 GB og planlægge med 160 GB – at løbe tør for disk på en databaseserver er en betydeligt værre eftermiddag end at løbe tør for disk på en webserver.

IOPS fortjener mere vægt, end de normalt får. Alt, hvad en Supabase-app gør, går gennem Postgres. Langsom disk betyder langsomme forespørgsler, hvilket betyder langsomme API-svar, og ingen mængde CPU løser det. Dette er hovedårsagen til, at NVMe er ufravigelig for denne arbejdsbyrde, mens det bare er rart at have for mange andre.

Hvad skal man egentlig vurdere

Fire kriterier er vigtigere for Supabase end for en generel webhost:

Database-IOPS og latenstid. Læse- og skrivegennemstrømning og P95/P99-latens i stedet for gennemsnit. Lagringstype først, alt andet derefter.

Netværksstabilitet i realtid. Supabase overfører databaseændringer over WebSockets. Forbindelser, der holdes åbne i timevis, er ubøjelige over for ustabilt netværk på en måde, som almindelig HTTP-request-response-trafik ikke er, så ensartet latenstid og generøse forbindelsesgrænser er vigtige.

Skalering uden migrering. Databaser er det værste at migrere. En vært, hvor du kan tilføje RAM og CPU på stedet, i stedet for at genopbygge på en større instans og flytte data, er især værd at overveje her.

Implementerings- og nedtagningshastighed. Du skal genopbygge denne stak flere gange, mens du får miljøvariablerne korrekte. Hurtig provisionering og skabelon- eller IaC-support forvandler det fra en eftermiddag til et par minutter.

De 7 bedste VPS-udbydere til selvhostet Supabase

1. Hostinger — bedste pris-til-ydelse-forhold

Hostinger fører an på den specifikation, der betyder mest her: 8 GB RAM på det niveau, de fleste køber, på NVMe-lager. For en stak med femten containere med PostgreSQL i centrum er den kombination hele spillet - nok hukommelse til, at Postgres kan holde et rigtigt fungerende sæt i buffere, og en hurtig nok disk til, at de forespørgsler, der rammer lageret, ikke stopper API'en.

Dens Docker-værktøjer håndterer Compose-stakken uden problemer, og du beholder root-adgang til det konfigurationsarbejde, som den selvhostede Supabase uundgåeligt har brug for. Gratis ugentlige backups er vigtigere end normalt, når det, du sikkerhedskopierer, er en database.

KVM-virtualisering med dedikerede ressourcer er det andet krav, der stille og roligt bliver opfyldt — en stak på femten containere med oversolgt delt virtualisering er et dårligt tidspunkt.

Fordele: 8 GB på det praktiske niveau; NVMe med stærke, målte IOPS; KVM med dedikerede ressourcer; Docker-værktøjer; gratis ugentlige sikkerhedskopier; firewall inkluderet; 30-dages pengene-tilbage-garanti.

Ulemper: Tilbudspriser kræver en lang forudbetalingsperiode og fornyes højere; skalering ud over planstigen betyder en migrering på et tidspunkt.

Hvem det er til: De fleste selvhostede Supabase-implementeringer, fra staging til lille produktion.

Check (Skak) Hostinger's nuværende VPS-priser →

2. DigitalOcean — den bedste udvikleroplevelse

DigitalOcean er det rigtige valg, når de omgivende værktøjer er lige så vigtige som selve kassen. Dokumentationen om kørsel af containeriserede Postgres-workloads er virkelig god, API'en og CLI'en gør miljøet reproducerbart, og snapshots giver dig mulighed for at tjekke en fungerende stak før en Supabase-versionsopgradering – hvilket du, givet hvor mange bevægelige dele der er involveret, vil ønske mindst én gang.

Den tilbyder også separat administreret PostgreSQL, hvilket er værd at vide om: en legitim mellemvej er selvhosting af Supabase-tjenesterne, mens de peger på en administreret database, så en anden ejer backups, failover og versionsopgraderinger for den del, der betyder mest.

Værdien pr. gigabyte er den svageste her, og det er en hukommelseskrævende arbejdsbyrde.

Fordele: fremragende dokumentation og API; stærke snapshots; administreret Postgres tilgængelig som en mellemvej; privat netværk; 99.99% SLA; globale regioner.

Ulemper: dyreste RAM på denne liste; sikkerhedskopier tilføjer ~20%; ingen pengene-tilbage-garanti.

Hvem det er til: teams, der ønsker reproducerbar infrastruktur og måske opdeler databasen.

Tjek DigitalOceans aktuelle priser →

3. Vultr — bedste globale rækkevidde

Vultrs relevans for Supabase er realtid. Hvis dine brugere er geografisk spredt og har WebSocket-forbindelser, forbedrer det at sidde tæt på dem oplevelsen markant – og Vultr har en af ​​de bredeste regionslister, der er tilgængelige.

Højfrekvente instanser med NVMe hjælper også på databasesiden, da hurtigere kerner og hurtig lagring tilsammen reducerer forespørgselsforsinkelse i marginerne.

Ingen skabelon, ingen pengene-tilbage-garanti, og konsollen forudsætter kompetence.

Fordele: meget bredt områdevalg til latenstidsfølsom realtid; højfrekvente NVMe-instanser; konkurrencedygtige priser; godt skaleringsområde.

Ulemper: ingen Supabase-skabelon; ingen pengene-tilbage-garanti; utilitaristiske værktøjer.

Hvem det er til: Apps med geografisk distribuerede brugere, der er afhængige af realtid.

4. AWS (EC2) — bedst til virksomheder og compliance

AWS er ​​her for de tilfælde, hvor kravet ikke er teknisk. Overholdelsesordninger, indkøbsstandarder, eksisterende virksomhedsaftaler eller en organisation, der allerede kører alt andet på AWS – det er reelle begrænsninger, og EC2 besvarer dem.

De tekniske fordele følger: RDS, hvis du ønsker, at databasen skal administreres og adskilles, EBS-volumener, du kan ændre i størrelse uden at genopbygge, og effektivt ubegrænset skaleringskapacitet.

Omkostningerne er kompleksitet og pris. EC2-prissætningen er virkelig svær at forudsige for en arbejdsbyrde som denne, når man tæller lagerplads, overførsel og support med, og konsollen er en løbende skat på din opmærksomhed. For en lille, selvhostet Supabase-instans er det væsentligt mere platform, end jobbet kræver.

Fordele: alle compliance-certificeringer; RDS til en administreret database; justerbar EBS-lagerplads; ubegrænset skalering; passer til eksisterende AWS-systemer.

Ulemper: Sværest at forudsige priser her; betydelig driftsmæssig kompleksitet; overkill til små implementeringer.

Hvem det er til: virksomheder, regulerede miljøer og teams, der allerede er standardiseret på AWS.

5. Jernbane — bedst til øjeblikkelig implementering

Jernbane er den hurtigste vej fra ingenting til en kørende Supabase-lignende stak. Det er en platform snarere end en server: du implementerer tjenester, den håndterer infrastrukturen, og der er intet operativsystem at opdatere.

For prototypefremstilling, interne værktøjer og projekter, hvor udviklertid koster mere end beregning, er det en stærk handel.sage-baseret prissætning betyder, at et stille projekt koster meget lidt.

Afvejningerne er de sædvanlige PaaS-afvejninger. Mindre kontrol på lavt niveau, usage-baseret fakturering, der er sværere at forudsige, efterhånden som trafikken vokser, og du bygger på deres abstraktioner i stedet for almindelig Docker. For en stak med femten containere ville du typisk implementere tjenesterne individuelt i stedet for at fjerne standard Compose-filen i sin helhed.

Fordele: hurtigste implementering; ingen serveradministration; usage-baseret prisfastsættelse passer til stille projekter; ren udvikleroplevelse.

Ulemper: mindre kontrol end en VPS; omkostninger mindre forudsigelige i stor skala; ikke en drop-in til standard Compose-stakken.

Hvem det er til: prototyper, interne værktøjer og teams, der hellere ikke vil køre servere.

Tjek Railways aktuelle priser →

6. Hetzner — bedste RAM pr. dollar

Med en arbejdsbelastning, der kræver så meget hukommelse, er prisen pr. gigabyte tæt på den samlede beslutning, og Hetzner vinder den. Omkring €13.99 får 4 vCPU og 8 GB - produktionsniveauet med reel trafik - for omtrent hvad en 4 GB instans koster i premium-enden.

Tilslutbare volumener er særligt relevante her: databaselager vokser, og muligheden for at tilføje disk uden at migrere serveren er præcis den "skalering uden migrering"-egenskab, som Supabase-implementeringer har brug for.

Ingen skabelon, ingen publiceret SLA, ekstra backups og tilmeldingsbekræftelse kan være langsommeligt. For en produktionsdatabase fortjener den manglende SLA oprigtig overvejelse snarere end et skuldertræk.

Fordele: langt den bedste RAM pr. dollar; tilknyttede volumener til voksende databaser; NVMe; timefakturering med et forbrugsloft; GDPR-kompatible placeringer.

Ulemper: ingen publiceret SLA, hvilket betyder mere for en database end en webserver; ingen skabelon; ekstra sikkerhedskopier; tilmeldingsfriktion.

Hvem det er til: Omkostningsbevidste implementeringer, der kræver reel hukommelse, hvor ingen SLA er acceptabel.

Tjek Hetzners aktuelle priser →

7. Liquid Web — den bedste administrerede løsning

Liquid Web er svaret for teams, der ønsker selvhostede Supabases økonomi uden at eje serverlaget. De administrerede niveauer placerer OS-patching, overvågning og incidentrespons hos en anden, hvilket for en stak, der indeholder din produktionsdatabase, er et forsvarligt køb snarere end en overbærenhed.

Selvadministrerede planer starter lavt og giver fuld root-adgang, hvis du hellere vil gøre det selv.

Ingen Supabase-specifikke værktøjer, ingen pengene-tilbage-garanti, og administrerede niveauer koster betydeligt mere, end startprisen antyder.

Fordele: ægte administreret løsning; stærkt supportomdømme; solid hardware og NVMe; fuld root-adgang på selvadministreret platform.

Ulemper: ingen Supabase-skabelon; ingen pengene-tilbage-garanti; administrerede niveauer er et betydeligt pristrin.

Hvem det er til: teams, der kører Supabase i produktion uden en dedikeret driftsperson.

Tjek Liquid Webs aktuelle priser →

Selvhostet eller administreret?

Selvhosting med Supabase giver dig den samme kernefunktionalitet — Postgres, Auth, Storage, Realtime, Edge Functions — til en brøkdel af den administrerede pris, med faste omkostninger i stedet for u.sage-baseret fakturering og ingen grænser for databasevækst.

Det, du giver afkald på, er bekvemmeligheden ved dashboardet og, endnu vigtigere, det operationelle ansvar. Du konfigurerer via filer og miljøvariabler i stedet for en brugergrænseflade, du håndterer opgraderinger manuelt på tværs af femten containere, og community-support erstatter en supportkontrakt.

Selvvært når: omkostninger hos digsage niveau er meningsfuldt, du har brug for dataopbevaring eller fuld kontrol, du er fortrolig med Docker og grundlæggende serveradministration, eller forudsigelige faste priser er vigtigere end bekvemmelighed.

Brug administreret når: Dashboard-workflowet er vigtigt for dit team, ingen ønsker at eje databaseoperationer eller din brugerflade.sage er lav nok til, at administreret prissætning er virkelig billig. For et lille projekt er det svært at slå de gratis og lave niveauer af administreret Supabase på den samlede pris, når man først har prissat sin egen tid.

Den ærlige middelvej er værd at gentage: selvhost Supabase-tjenesterne, men peg dem mod en administreret PostgreSQL-instans. Du bevarer omkostningskontrollen og mister den del af jobbet med de værste fejltilstande.

Hvordan vi valgte

Vi vægtede de kriterier, der er vigtige for en databasecentreret stak med flere containere: hukommelse til realistiske priser, lagertype og IOPS, om du kan skalere RAM og disk uden at migrere, netværkskonsistens for langlivede WebSocket-forbindelser og håndtering af backup. Hukommelse og disk vægtes hårdest, fordi PostgreSQL er den komponent, der bestemmer, om hele platformen føles hurtig.

Kravtallene afspejler den offentliggjorte vejledning til selvhostede Supabase snarere end vores egen belastningstest, og vi har angivet intervallet i stedet for et enkelt tal, fordi udvikling og produktion reelt adskiller sig med en faktor fire eller mere. Prissætningen er hver udbyders offentliggjorte pris på tidspunktet for skrivningen. To af de syv udbydere her tjener os ingenting.

Hvordan vælger

1. Udvikling eller produktion? 2GB virker virkelig til førstnævnte og fejler virkelig til sidstnævnte.
2. Prioriter NVMe og IOPS over CPU. Alt går gennem Postgres.
3. Kan du tilføje RAM og disk på stedet? Migrering af en database er det, du allermest ønsker at undgå.
4. Betyder realtid noget? Hvis brugerne har WebSocket-forbindelser, rykker regionens nærhed og netværkskonsistens op på listen.
5. Prissæt det i forhold til administreret før du forpligter dig — inklusive din egen tid på opgraderinger og sikkerhedskopier.

For de fleste mennesker er det Hostinger — 8 GB på NVMe på det niveau, du rent faktisk ville købe, er den korrekte form til denne stak. Hetzner hvis prisen pr. gigabyte dominerer, og ingen SLA er acceptabel, DigitalOcean til værktøjer og den administrerede databases mellemsti, Vultr for globalt distribueret realtid, Jernbane at springe servere helt over, Liquid Web hvis du vil have det administreret, og AWS når compliance eller et eksisterende dødsbo bestemmer det for dig.

Ofte stillede spørgsmål

Hvad er minimumskravene for selvhostet Supabase?

En udviklings- eller minimal staging-instans kører på 2 GB RAM og 1-2 vCPU'er. Til produktion er 4 GB og 2 vCPU'er den realistiske grænse, og 8-16 GB er, hvor en app med reel trafik hører hjemme. NVMe-lagerplads er vigtigere end CPU, fordi alt ruter gennem PostgreSQL. Start ved 80 GB diskplads, og planlæg med 160 GB, når data, logfiler og sikkerhedskopier er akkumuleret.

Hvorfor har Supabase brug for så meget RAM?

Fordi det ikke er én applikation – kører den selvhostede Supabase cirka femten Docker-containere: PostgreSQL, GoTrue til godkendelse, PostgREST til API'en, Realtime, Storage, Kong som gateway, Studio til dashboardet og supporttjenester. PostgreSQL alene kræver 1-2 GB plads til et brugbart arbejdssæt, og de resterende containere plus OS og Docker-overhead bruger resten af ​​en lille boks.

Er selvhosting af Supabase billigere end den administrerede tjeneste?

Ved meningsfuld usage, væsentligt — du bytter digsage-baseret prisfastsættelse for en fast månedlig serverpris uden begrænsninger på databasestørrelse. I lille skala er administreret ofte billigere, når du værdsætter din egen tid, da du påtager dig opgraderinger på tværs af femten containere, backupverifikation og hændelsesrespons. Mellemvejen er selvhosting af tjenesterne mod en administreret PostgreSQL-instans.

Kan jeg køre selvhostet Supabase på en 2GB VPS?

Til udvikling, ja. Til produktion, nej — PostgreSQL skal bruge 1-2 GB, før de andre containere starter, så en 2 GB-boks har intet tilovers. Den vil se ud til at virke i test og derefter forringes, så snart der ankommer reel trafik, fordi Postgres vil læse fra disken for forespørgsler, den burde betjene fra hukommelsen. 4 GB er det ærlige produktionsminimum.

Relaterede blogindlæg

• Den bedste VPS til Docker
• Den bedste VPS til Coolify
• De bedste VPS-hostingtjenester
• Hetzner vs DigitalOcean