EQVPS

VPS för en databas

Självhosta PostgreSQL eller Redis på en VPS med full root — hela postgresql.conf, tillägg som en managed tjänst inte låter dig installera, och ärliga gränser för vad en delad box klarar och inte klarar. Från $8/mån.

Det finns ett specifikt ögonblick där en managed databas slutar vara bekväm och börjar vara en vägg. Du vill ha ett tillägg som nivån inte erbjuder. Du vill se den faktiska query-planen och tuna work_mem. Du vill ha en superuser. En managed tjänst är ett utmärkt standardval ända fram till den punkt där du behöver äga saken — och då är en VPS med full root det ärliga svaret.

Den här sidan handlar om att köra din egen PostgreSQL eller Redis korrekt, och om att vara tydlig med var en delad box är rätt val och var det inte är det.

Vad en databas faktiskt behöver

Databaser bryr sig om två saker som en gameserver inte gör: minne för working set och disk-I/O. Den grova formen:

Redis är ännu lättare — den är minnesbunden, så dimensionera planet efter din dataset plus overhead så är du klar. Postgres är den som belönar lite tuning.

Den verkliga anledningen att självhosta: kontroll

Det är här en VPS förtjänar sin plats. På din egen box får du:

Om inget av det spelar roll för dig är en managed databas verkligen bra och du bör använda en. Den här sidan är för fallet där det gör det.

Där en delad box är fel verktyg

För att vara rak om det: en shared-vCPU-VPS är inte byggd för tung OLTP — hundratals transaktioner i sekunden med latenskritiska skrivningar. Den workloaden lever eller dör på garanterad disk-I/O och en stadig klocka, och delade planer lovar ingetdera. Om det är du vill du ha dedikerad hårdvara, och vi berättar det hellre nu än ser din p99-latens skämma ut oss båda.

För det mycket vanligare fallet — en databas bakom en app, ett internt verktyg, en analytics-lagring, en cache — är ett delat plan precis rätt.

Säkerhetskopior är inte valfria

Att självhosta innebär att säkerhetskopior är ditt jobb, och den enda regeln är: gör dem innan du behöver dem. För Postgres, pg_dump på en cron för logiska säkerhetskopior, eller WAL-arkivering för point-in-time recovery på allt du faktiskt bryr dig om. Skeppa dumparna bort från boxen — till objektlagring eller en annan server — så att en död disk inte tar säkerhetskopiorna med sig. Testa en återställning minst en gång. En säkerhetskopia du aldrig återställt är ett hopp, inte en säkerhetskopia.

Att låta andra servrar ansluta

Om databasen bara betjänar en app på samma box, bind den till localhost så är du klar — inget att exponera. I det ögonblick en annan maskin måste in ändras två saker:

  1. Du behöver en stabil, routbar adress — det är ett dedikerat-IPv4-plan (Small-IP $16, Medium-IP $20). NAT-planer delar en adress, vilket är bra för utgående men inte för att vara en databas som andra servrar ringer in till.
  2. Du brandväggsskyddar den hårt. Öppna 5432 (eller 6379) bara för de specifika IP:er som behöver den, aldrig för 0.0.0.0/0, och kräv TLS. En öppen Postgres-port på det publika internet hittas på minuter.

Att välja planet

UppsättningPlan
DB bakom en app, endast localhostSmall ($8)
Ett par appar / produktionssamtidighetMedium ($12)
Andra servrar måste ansluta inSmall-IP ($16) / Medium-IP ($20)
Tung OLTP, hundratals TPSdedikerad hårdvara, inte en delad VPS

De flesta självhostade databaser börjar på Small och växer in i Medium eller ett dedikerat-IP-plan när de tar på sig fler appar eller externa klienter.

Varför här

Full root innebär att det är din databas, hela vägen ner — varje konfigurationsrad, varje tillägg, ditt eget säkerhetskopieringsschema, ingen nivå som bestämmer vad du får installera. Betalning är krypto (USDC eller USDT på Base, Ethereum eller Polygon), ingen KYC, inga dokument. Root på ungefär 60 sekunder efter betalning, och du kan ha Postgres som accepterar anslutningar några minuter senare.

Den ärliga sammanfattningen: självhosta när du vill ha kontroll — tillägg, tuning, superuser — och när din workload är måttlig. För en liten-till-medelstor apps databas är ett delat plan rätt verktyg. För hundratals TPS av latenskritisk OLTP är det inte det, och vi säger det. Redo? Välj ett plan.

Redo att distribuera? Betala med krypto, ingen KYC — igång på ungefär en minut.

Distribuera nu →

FAQ

Hur mycket RAM behöver en självhostad databas?

För en app — en Postgres- eller Redis-instans plus dess backend — är 1,7-2 GB en realistisk working set, så Small ($8) passar. Flera appar, eller en produktionsdatabas med verklig samtidighet, driver dig till Medium ($12), och om andra maskiner måste nå den, ett dedikerat-IP-plan. Dimensionera efter working set och anslutningsantal, inte efter hopp.

Varför självhosta istället för en managed databas?

Kontroll. Du får hela postgresql.conf, superuser, och vilket tillägg du vill — pgvector, PostGIS, TimescaleDB, pg_cron — saker som managed-nivåer ofta låser eller tar extra betalt för. Avvägningen är att säkerhetskopior, tuning och uppgraderingar är dina att köra. Om du vill äga boxen är detta poängen.

Är en delad VPS okej för en produktionsdatabas?

För en liten till måttlig app, ja. För tung OLTP — hundratals transaktioner i sekunden, latenskritiska skrivningar — är en shared-vCPU-box fel verktyg, och vi säger det hellre än att sälja dig en. Disk-I/O och en garanterad klocka spelar roll där, och delade planer lovar ingetdera.

Hur låter jag mina andra servrar ansluta till databasen?

Bind Postgres till rätt gränssnitt, öppna porten bara för de IP:er som behöver den, och använd ett plan med en dedikerad IPv4 så att adressen är stabil och nåbar. Exponera aldrig 5432 för hela internet — brandväggsskydda den till dina appservrar och kräv TLS.

Måste jag ge er ett ID?

Nej. E-post för att registrera dig, USDC eller USDT för att betala. Inga dokument, root på ungefär en minut.

Kommentarer

Inga kommentarer än. Bli först.

Lämna en kommentar

Kommentarer modereras innan de visas.