−25%

la planurile Windows anuale, până pe 31 oct. Vezi planurile

EQVPS
Începe

VPS pentru o bază de date

Găzduiește PostgreSQL sau Redis pe un VPS cu root complet — tot postgresql.conf, extensii pe care un serviciu administrat nu te lasă să le instalezi și limite cinstite despre ce poate și ce nu poate duce un server cu vCPU împărțite. De la $8/lună.

Există un moment anume în care o bază de date administrată nu mai e comodă și devine un zid. Vrei o extensie pe care nivelul tău nu o oferă. Vrei să vezi planul real al interogării și să ajustezi work_mem. Vrei un superuser. Un serviciu administrat e o alegere implicită excelentă până în clipa în care trebuie să deții lucrul ăsta — iar atunci un VPS cu root complet e răspunsul cinstit.

Pagina asta e despre cum rulezi corect propriul PostgreSQL sau Redis și despre unde un server cu resurse împărțite e alegerea bună și unde nu.

De ce are nevoie de fapt o bază de date

Bazelor de date le pasă de două lucruri de care unui server de jocuri nu-i pasă: memorie pentru setul de lucru și I/O pe disc. Forma aproximativă:

  • O aplicație — o instanță Postgres (sau Redis) plus un serviciu de backend. Setul de lucru e de obicei 1,7-2 GB. Small ($8) îl duce fără dramă.
  • Câteva aplicații sau concurență reală de producție — mai multe conexiuni, cache-uri mai mari, sarcini de fundal. Medium ($12) îți dă rezerva.
  • Alte mașini trebuie să ajungă la ea — vrei o adresă stabilă, rutabilă, deci un plan cu IPv4 dedicat (Small-IP $16 și în sus). Mai multe despre asta mai jos.

Redis e și mai ușor — e legat de memorie, deci dimensionezi planul după setul de date plus overhead și ai terminat. Postgres e cel care răsplătește puțină ajustare.

Motivul real să găzduiești singur: controlul

Aici își merită locul un VPS. Pe propria mașină primești:

  • Tot postgresql.conf — shared_buffers, work_mem, max_connections, setările WAL, tot, ajustate pe sarcina ta, nu pe valorile implicite ale unui furnizor.
  • Orice extensie. pgvector pentru embeddinguri și căutare semantică, PostGIS pentru date geospațiale, TimescaleDB pentru serii de timp, pg_cron, pg_stat_statements — instalezi ce-ți trebuie. Nivelurile administrate restrâng des lista de extensii sau o țin în spatele unui plan mai scump.
  • Superuser și sistemul de operare de dedesubt. Poți muta directorul de date, ajusta kernelul, rula pg_dump după programul tău și configura replicare în flux către altă mașină, dacă vrei.

Dacă nimic din toate astea nu contează pentru tine, o bază de date administrată e chiar în regulă și ar trebui s-o folosești. Pagina asta e pentru cazul în care contează.

Unde un server cu resurse împărțite e unealta greșită

Direct: un VPS cu vCPU împărțite nu e construit pentru OLTP greu — sute de tranzacții pe secundă, cu scrieri critice la latență. Sarcina asta trăiește sau moare prin I/O garantat pe disc și o frecvență constantă, iar planurile cu resurse împărțite nu promit niciuna. Dacă ești în situația asta, vrei hardware dedicat și preferăm să-ți spunem acum decât să ne uităm cum latența ta p99 ne face de rușine pe amândoi.

Pentru cazul mult mai frecvent — o bază de date în spatele unei aplicații, o unealtă internă, un depozit de analiză, un cache — un plan cu resurse împărțite e exact ce trebuie.

Backup-urile nu sunt opționale

Să găzduiești singur înseamnă că backup-urile sunt treaba ta, iar singura regulă e: fă-le înainte să ai nevoie de ele. Pentru Postgres, pg_dump pe cron pentru backup-uri logice sau arhivare WAL pentru recuperare la un moment dat, pe orice ține cu adevărat la tine. Trimite dumpurile în afara mașinii — în object storage sau pe alt server — ca un disc mort să nu ia și backup-urile cu el. Testează o restaurare măcar o dată. Un backup pe care nu l-ai restaurat niciodată e o speranță, nu un backup.

Cum le permiți altor servere să se conecteze

Dacă baza de date servește doar o aplicație de pe aceeași mașină, leag-o de localhost și ai terminat — nimic de expus. În clipa în care altă mașină trebuie să intre, se schimbă două lucruri:

  1. Ai nevoie de o adresă stabilă, rutabilă — asta înseamnă un plan cu IPv4 dedicat (Small-IP $16, Medium-IP $20). Planurile NAT nu au o adresă publică proprie, ceea ce merge pentru traficul spre exterior, dar nu pentru o bază de date la care se conectează alte servere.
  2. O pui strict după firewall. Deschizi 5432 (sau 6379) doar pentru IP-urile concrete care au nevoie, niciodată pentru 0.0.0.0/0, și ceri TLS. Un port Postgres deschis pe internetul public e găsit în câteva minute.

Alegerea planului

ConfigurarePlan
BD în spatele unei aplicații, doar localhostSmall ($8)
Câteva aplicații / concurență de producțieMedium ($12)
Alte servere trebuie să se conectezeSmall-IP ($16) / Medium-IP ($20)
OLTP greu, sute de TPShardware dedicat, nu un VPS cu resurse împărțite

Cele mai multe baze de date găzduite singur pornesc pe Small și cresc spre Medium sau un plan cu IP dedicat pe măsură ce preiau mai multe aplicații sau clienți externi.

De ce aici

Root complet înseamnă că e baza ta de date, până la capăt — fiecare linie de configurare, fiecare extensie, propriul program de backup, niciun nivel care să decidă ce ai voie să instalezi. Plata e cripto (USDC sau USDT pe Base, Ethereum sau Polygon), fără KYC, fără documente. Root în aproximativ 60 de secunde după plată, iar Postgres poate accepta conexiuni câteva minute mai târziu.

Recapitularea cinstită: găzduiește singur când vrei control — extensii, ajustare, superuser — și când sarcina ta e moderată. Pentru baza de date a unei aplicații mici sau medii, un plan cu resurse împărțite e unealta potrivită. Pentru sute de TPS de OLTP critic la latență, nu e, și îți vom spune asta. Gata? Alege un plan.

Gata de deploy? Plătește cu cripto, fără KYC — online în aproximativ un minut.

Pornește acum →

Întrebări frecvente

De câtă RAM are nevoie o bază de date găzduită de mine?

Pentru o singură aplicație — o instanță Postgres sau Redis plus backendul ei — 1,7-2 GB e un set de lucru realist, deci Small ($8) se potrivește. Mai multe aplicații sau o bază de date de producție cu concurență reală te împing spre Medium ($12), iar dacă alte mașini trebuie să ajungă la ea, spre un plan cu IP dedicat. Dimensionează după setul de lucru și numărul de conexiuni, nu după speranță.

De ce să găzduiesc singur în loc să folosesc o bază de date administrată?

Control. Primești tot postgresql.conf, superuser și orice extensie vrei — pgvector, PostGIS, TimescaleDB, pg_cron — lucruri pe care nivelurile administrate le blochează des sau le taxează în plus. Compromisul e că backup-urile, ajustarea și actualizările le faci tu. Dacă vrei să deții mașina, asta e ideea.

E un VPS cu vCPU împărțite în regulă pentru o bază de date de producție?

Pentru o aplicație mică sau medie, da. Pentru OLTP greu — sute de tranzacții pe secundă, scrieri critice la latență — un server cu vCPU împărțite e unealta greșită și preferăm să-ți spunem asta decât să-ți vindem unul. Acolo contează I/O-ul pe disc și o frecvență garantată, iar planurile cu resurse împărțite nu promit niciuna dintre ele.

Cum le permit celorlalte servere să se conecteze la baza de date?

Leagă Postgres de interfața potrivită, deschide portul doar pentru IP-urile care au nevoie de el și folosește un plan cu IPv4 dedicat, ca adresa să fie stabilă și accesibilă. Nu expune niciodată 5432 către tot internetul — pune-l după firewall, deschis doar serverelor de aplicație, și cere TLS.

Trebuie să vă dau un act de identitate?

Nu. E-mail la înregistrare, USDC sau USDT la plată. Fără documente, root în aproximativ un minut.

Comentarii

Încă nu există comentarii. Fii primul.

Lasă un comentariu

Comentariile sunt moderate înainte să apară.