EQVPS

VPS за база данни

Хоствай сам PostgreSQL или Redis на VPS с пълен root — целия postgresql.conf, разширения, които managed услуга няма да ти позволи да инсталираш, и честни граници за това какво споделена машина може и не може да поеме. От $8/месец.

Има специфичен момент, в който managed база данни спира да е удобна и започва да е стена. Искаш разширение, което нивото не предлага. Искаш да видиш реалния query plan и да настроиш work_mem. Искаш superuser. Managed услуга е чудесен по подразбиране точно докато не се нуждаеш да притежаваш нещото — и тогава VPS с пълен root е честният отговор.

Тази страница е за пускането на собствен PostgreSQL или Redis правилно, и за яснотата къде споделена машина е правилният избор и къде не.

Какво реално се нуждае база данни

Базите данни държат на две неща, на които game сървър не държи: памет за работния набор и диск I/O. Грубата форма:

Redis е още по-лек — той е ограничен от паметта, така че оразмери плана към dataset-а си плюс overhead и си готов. Postgres е този, който възнаграждава малко tuning.

Реалната причина да хостваш сам: контрол

Тук VPS печели мястото си. На собствената си машина получаваш:

Ако нищо от това няма значение за теб, managed база данни е генуинно наред и трябва да използваш такава. Тази страница е за случая, когато има.

Къде споделена машина е грешният инструмент

Направо за него: споделено-vCPU VPS не е построен за тежко OLTP — стотици транзакции в секунда с критични за латентност записи. Това натоварване живее или умира от гарантиран диск I/O и стабилен clock, а споделените планове не обещават нито едно. Ако това си ти, искаш dedicated хардуер, и предпочитаме да ти кажем сега, отколкото да гледаме как p99 латентността ти засрамва и двама ни.

За далеч по-честия случай — база данни зад едно приложение, вътрешен инструмент, аналитично хранилище, кеш — споделен план е точно правилен.

Backup-ите не са опционални

Хостването значи, че backup-ите са твоя работа, и единственото правило е: прави ги преди да се нуждаеш от тях. За Postgres, pg_dump на cron за логически backup-и, или WAL архивиране за point-in-time recovery на всичко, за което реално те е грижа. Изпращай дъмповете извън машината — към object storage или друг сървър — така че мъртъв диск да не отнесе backup-ите със себе си. Тествай restore поне веднъж. Backup, който никога не си възстановявал, е надежда, не backup.

Позволяване на други сървъри да се свързват

Ако базата данни обслужва само приложение на същата машина, върни я към localhost и си готов — нищо за излагане. В мига, в който друга машина трябва да влезе, две неща се променят:

  1. Нуждаеш се от стабилен, маршрутизируем адрес — това е план с dedicated IPv4 (Small-IP $16, Medium-IP $20). NAT плановете споделят адрес, което е наред за изходящо, но не за това да си база данни, в която други сървъри се набират.
  2. Firewall-ваш го твърдо. Отвори 5432 (или 6379) само към конкретните IP-та, които се нуждаят, никога към 0.0.0.0/0, и изисквай TLS. Отворен Postgres порт на публичния интернет се намира за минути.

Избор на план

НастройкаПлан
DB зад едно приложение, само localhostSmall ($8)
Няколко приложения / продукционна concurrencyMedium ($12)
Други сървъри трябва да се свързватSmall-IP ($16) / Medium-IP ($20)
Тежко OLTP, стотици TPSdedicated хардуер, не споделен VPS

Повечето self-hosted бази данни започват на Small и растат в Medium или план с dedicated IP, докато поемат повече приложения или външни клиенти.

Защо тук

Пълен root значи, че е твоята база данни, докрай — всеки конфиг ред, всяко разширение, собствения ти backup график, без ниво, решаващо какво ти е позволено да инсталираш. Плащането е crypto (USDC или USDT на Base, Ethereum или Polygon), без KYC, без документи. Root за около 60 секунди след плащане, и можеш да имаш Postgres, приемащ връзки, няколко минути по-късно.

Честното резюме: хоствай сам, когато искаш контрол — разширения, tuning, superuser — и когато натоварването ти е умерено. За база данни на малко-до-средно приложение, споделен план е правилният инструмент. За стотици TPS критично за латентност OLTP, не е, и ще го кажем. Готов? Избери план.

Готов за deploy? Плати в crypto, без KYC — онлайн за около минута.

Deploy-ни сега →

Въпроси

Колко RAM се нуждае self-hosted база данни?

За едно приложение — Postgres или Redis инстанция плюс backend-а ѝ — 1.7-2 GB е реалистичен работен набор, така че Small ($8) приляга. Няколко приложения, или продукционна база данни с реална concurrency, те бутат към Medium ($12), и ако други машини трябва да я достигнат, план с dedicated IP. Оразмерявай по работен набор и брой връзки, не по надежда.

Защо да хоствам сам вместо managed база данни?

Контрол. Получаваш целия postgresql.conf, superuser, и всяко разширение, което искаш — pgvector, PostGIS, TimescaleDB, pg_cron — неща, които managed нива често заключват или таксуват допълнително. Компромисът е, че backup-ите, tuning-ът и ъпгрейдите са твои за пускане. Ако искаш да притежаваш машината, това е смисълът.

Споделен VPS наред ли е за продукционна база данни?

За малко-до-умерено приложение, да. За тежко OLTP — стотици транзакции в секунда, критични за латентност записи — машина със споделено vCPU е грешният инструмент, и ще го кажем, вместо да ти продадем такава. Диск I/O и гарантиран clock имат значение там, а споделените планове не обещават нито едно.

Как да позволя на другите си сървъри да се свържат с базата данни?

Върни Postgres към правилния интерфейс, отвори порта само към IP-тата, които се нуждаят, и използвай план с dedicated IPv4, така че адресът да е стабилен и достижим. Никога не излагай 5432 към целия интернет — firewall-ни го към app сървърите си и изисквай TLS.

Трябва ли да ви дам документ?

Не. Имейл за регистрация, USDC или USDT за плащане. Без документи, root за около минута.

Коментари

Още няма коментари. Бъди първият.

Остави коментар

Коментарите се модерират преди да се появят.