Managed va serverless Postgres: Neon, Supabase, RDS — nima olasiz va nima qoladi

Qisqacha: Managed Postgres — serverni, yangilashni, zaxirani va monitoringni provayder boshqaradigan Postgres: siz faqat ulanish satrini olasiz. Serverless variant (Neon) ishlatilmaganda o'chib turadi va har branch'ni bir lahzada nusxalaydi. Bularning narxi — superuser yo'q, extension ro'yxati cheklangan, ulanishlar soni tarifga bog'liq va ma'lumot provayder qoidasi bilan saqlanadi. pg_dump — har doim chiqish yo'li; rollar, sxema va zaxira tekshiruvi esa baribir sizning ishingiz.

Bu darsda

• O'zingiz boshqaradigan va managed Postgres o'rtasidagi mas'uliyat chegarasini tushuntirasiz.
• Neon (branching, scale to zero), Supabase va AWS RDS ning asosiy farqlarini bilasiz.
• Ulanish limiti, pooler va to'g'ridan manzil masalasini hisoblay olasiz.
• Vendor lock-in va undan chiqish yo'lini baholaysiz.
• O'zbekistondagi shaxsiy ma'lumot qonunining saqlash joyiga ta'sirini bilasiz.

Oldin bilishingiz kerak: Backup va restore, PgBouncer va tashqi pooler'lar, Extension'lar, Postgres versiyasini yangilash.

1. Nega bu kerak?

Oxirgi to'rt darsda biz Postgres'ning "egasi" bo'lib ishladik: zaxira oldik, PITR qildik, qulf zanjirini uzdik, 17 dan 18 ga ko'tardik. Bularning hammasi — vaqt, bilim va kechasi uyg'otadigan ogohlantirishlar.

Endi savol: kichik jamoa yoki bitta dasturchi uchun bu ishni o'zi qilish shartmi? Ko'p startaplar "yo'q" deydi va bazani xizmatga topshiradi — managed (boshqariladigan) Postgres. Siz panelda tugma bosasiz va ulanish satrini olasiz: postgres://…@…neon.tech/…. Zaxira, yangilash, disk, monitoring — provayderda.

Lekin "hammasi provayderda" — aldamchi gap. Provayder serverni boshqaradi, ma'lumotingizni emas. Sxema xatosi, WHERE siz DELETE, zaif rol, noto'g'ri ulanish sozlamasi — baribir sizniki.

O'xshatish: uy ijarasi va o'z uyingiz. Ijarada tom oqsa, uy egasi tuzatadi (provayder). Lekin xonangizdagi narsalarni o'zingiz tartiblaysiz, devorni buzishga esa ruxsat yo'q (superuser yo'q). Ko'chib o'tmoqchi bo'lsangiz, narsalaringizni o'zingiz yig'asiz (pg_dump).

Diqqat: Bu dars to'liq hujjat bo'yicha: kanon hech qanday provayderda hisob ochmadi — Neon, Supabase, AWS RDS/Aurora, Railway, DigitalOcean sinalmagan. Raqamlar provayderlarning rasmiy hujjatidan, 2026-10-26 da o'qildi; tariflar tez o'zgaradi — tanlashdan oldin qayta tekshiring. Bizning o'z misollarimiz — PostgreSQL 17.6, o'z klasterimizda.

2. Mas'uliyat chegarasi

2.1 Kim nima qiladi

Oxirgi uch qator — eng ko'p unutiladigan. Provayder zaxira oladi, lekin uni sizning ilovangiz bilan tiklab, ishlashini tekshirish — sizning vazifangiz.

2.2 Superuser yo'q

O'z klasterimizda biz superuser'miz:

SELECT current_user, rolsuper
FROM pg_roles
WHERE rolname = current_user;

Natija (PostgreSQL 17.6):

 current_user | rolsuper
--------------+----------
 postgres     | t
(1 row)

Managed xizmatda bu f bo'ladi: provayder sizga "deyarli admin" rolini beradi, lekin haqiqiy superuser emas. Natijada ba'zi narsalar mumkin emas: ALTER SYSTEM, server fayllarini o'qish (COPY … TO '/fayl' — Ma'lumotni qisman ko'chirish darsidagi server tomoni), ixtiyoriy C extension o'rnatish. \copy va pg_dump esa ishlaydi — ular mijoz tomonida.

3. Uch yondashuv

3.1 Klassik managed: AWS RDS

AWS RDS — sizga ajratilgan virtual server ichidagi Postgres, AWS boshqaradi. Siz kompyuter o'lchamini (CPU, RAM) va disk hajmini tanlaysiz, u doim ishlaydi va soatbay to'lanadi.

AWS hujjati bo'yicha (2026-10-26):

• Avtomatik zaxira — saqlash muddati 0 dan 35 kungacha (0 — o'chirilgan). Konsoldan yaratilganda sukut 7 kun, API/CLI orqali — 1 kun.
• Zaxira muddati ichida istalgan lahzaga tiklash (PITR) — natija yangi instans bo'ladi, eskisi o'zgarmaydi.
• Instansni o'chirishda "avtomatik zaxiralarni saqlash" tanlanmasa, avtomatik zaxiralar instans bilan birga o'chadi. Qo'lda olingan snapshot'lar esa qoladi.

Oxirgi band — klassik tuzoq: kimdir "eski test bazasini" o'chiradi, keyin ma'lum bo'ladiki, u prod ekan va zaxiralari ham ketgan.

Aurora — AWS'ning Postgres bilan mos, lekin saqlash qatlami qayta yozilgan varianti. U "Postgres bilan mos", lekin Postgres'ning o'zi emas: ba'zi xatti-harakatlar va extension'lar farq qiladi.

3.2 Serverless: Neon

Neon saqlash va hisoblashni (compute) ajratgan: ma'lumot umumiy omborda, Postgres jarayoni esa kerak bo'lganda ishga tushadi. Hujjat bo'yicha (2026-10-26) ikki asosiy imkoniyat:

Scale to zero — 5 daqiqa faoliyatsizlikdan keyin compute o'chadi va keyingi so'rovda "bir necha yuz millisekund" ichida qayta yonadi. Bepul tarifda bu o'chirilmaydi, pullik tariflarda — o'chirsa bo'ladi. Foydasi: o'quv loyihasi kechasi pul yemaydi. Narxi: birinchi so'rov sekinroq ("sovuq start"), sessiyadagi holat (PgBouncer darsidagi SET) saqlanishiga tayanmang.

Branching — bazaning copy-on-write nusxasi: yangi branch ota branch bilan ma'lumotni bo'lishadi va faqat o'zgarishlarni alohida yozadi. Shuning uchun 50 GB bazadan ham nusxa bir lahzada olinadi va otaga yuk tushirmaydi.

Branching nimaga kerak:

• Har pull request uchun alohida baza — migratsiyani prod nusxasida sinash (Prisma Migrate chuqur).
• Xatoli DELETE dan oldingi lahzadan branch ochib, kerakli qatorlarni olish — Ma'lumotni qisman ko'chirish darsidagi jarrohlik, faqat zaxirani tiklash shart emas.

Bu "o'tmishga qaytish" tarix oynasi bilan cheklangan: hujjat bo'yicha sukut — bepul tarifda 6 soat, pullikda 1 kun, maksimal — tarifga qarab 7 yoki 30 kun. Oyna qancha uzun bo'lsa, saqlash shuncha qimmat.

flowchart LR
  M[(main branch)] --> D[dev: bugun]
  M --> P[PR-42: migratsiya sinovi]
  M --> T[tiklash: kecha 18:39]

Diagrammada bitta asosiy branch'dan uchta nusxa: kundalik ishlash, migratsiya sinovi va xatodan oldingi lahza. Uchalasi ham asosiy ma'lumotni nusxalamaydi — faqat o'zgarishlarini saqlaydi.

3.3 Platforma: Supabase

Supabase — oddiy Postgres atrofida tayyor xizmatlar to'plami: autentifikatsiya, fayl ombori, avtomatik REST API, realtime. Baza — haqiqiy Postgres, unga psql bilan ham ulanasiz.

Zaxira bo'yicha hujjat (2026-10-26):

• Kunlik zaxira — faqat pullik tariflarda (Pro 7 kun, Team 14 kun, Enterprise 30 kungacha). Bepul tarif uchun hujjat o'zi supabase db dump bilan muntazam eksport qilishni tavsiya qiladi.
• PITR — qo'shimcha pullik xizmat; WAL har 2 daqiqada saqlanadi, ya'ni eng yomon holatda RPO 2 daqiqa (Backup darsidagi RPO).
• Muhim ogohlantirish: kunlik zaxiralarda o'zingiz yaratgan rollarning parollari saqlanmaydi — tiklagandan keyin ularni qayta o'rnatish kerak.

Oxirgi band Backup va restore darsidagi "rollar dump'da yo'q" muammosining provayderdagi ko'rinishi. Mexanizm boshqa, saboq bir xil: tiklash rejasida rollarni alohida o'ylang.

Uch yondashuvni bir jadvalda solishtiramiz (hujjat bo'yicha, 2026-10-26):

3.4 Boshqalar

Railway, Render, DigitalOcean Managed Databases va boshqalar — klassik managed modelga yaqin (doim ishlaydigan instans, kunlik zaxira, ulanish satri). Ular orasidagi farq ko'pincha narx, mintaqa (server qaysi davlatda) va zaxira muddatida. Hammasi sinalmagan.

Tekshirib ko'ring: Neon'da tarix oynasi 1 kun. Juma 18:40 da xatoli DELETE bo'ldi, siz uni dushanba ertalab payqadingiz. Branching yordam beradimi?

4. Ulanishlar: eng ko'p uchraydigan muammo

4.1 Limit tarifga bog'liq

Postgres'da har ulanish — alohida jarayon (Postgres arxitekturasi). Sukut chegarasi:

SHOW max_connections;

Natija:

 max_connections
-----------------
 100
(1 row)

O'z serveringizda bu sozlama — sizniki. Managed xizmatda max_connections odatda kompyuter o'lchamidan hisoblanadi: kichik tarifda kichik son. Serverless ilova (Vercel funksiyalari) har chaqiruvda yangi ulanish ochsa, bu limit bir zumda tugaydi — Connection pooling darsidagi hisob shu yerda hayotiy.

4.2 Ikki manzil

Ilova ichidagi hovuz (pool) (Connection pooling) bitta jarayonning ulanishlarini qayta ishlatadi. Lekin ilova nusxalari ko'p bo'lsa, har birining o'z hovuzi bor. Shuning uchun hamma provayder pooler beradi — ilova bilan Postgres orasidagi umumiy hovuz-xizmat (PgBouncer va tashqi pooler'lar): Neon'da host nomiga -pooler qo'shiladi, Supabase'da alohida port. Va ikki manzil naqshi:

Transaction rejimidagi pooler bilan migratsiya ishlatsangiz, sessiya qulfi va SET kabi narsalar buziladi — u holda migratsiya to'g'ridan manzil bilan.

Tekshirib ko'ring: Ilova Vercel'da, baza Neon'da. Har funksiya chaqiruvida new pg.Pool({ max: 10 }) yaratiladi. Nima bo'ladi va qanday tuzatiladi?

5. Extension'lar va versiya

Extension'lar darsida ko'rdik: postgres:18 image'ida postgis, pgvector, pg_cron yo'q edi — ular alohida o'rnatiladi. Managed xizmatda esa o'zingiz hech narsa o'rnata olmaysiz: provayder ruxsat bergan ro'yxat bilan cheklanasiz. Supabase hujjati 50 dan ortiq oldindan sozlangan extension va sof SQL extension'larni o'zingiz o'rnatish imkonini aytadi; C tilida yozilgan ixtiyoriy extension — yo'q.

Tanlashdan oldin tekshiradigan narsalar:

• Kerakli extension'lar ro'yxatda bormi va qaysi versiyada (masalan pg_trgm, unaccent — bizning o'zbekcha qidiruv uchun).
• Qaysi Postgres major versiyalari bor va yangisi qachon qo'shiladi.
• shared_preload_libraries talab qiladigan extension (pg_stat_statements) yoqilganmi.

Mavjud extension'lar soni o'rnatishga qarab farq qiladi: postgres:18 Docker image'ida kanon 46 tasini sanadi, bizning Windows'dagi PostgreSQL 17.6 da pg_available_extensions 61 ta qator qaytardi.

6. Vendor lock-in

Vendor lock-in (provayderga bog'lanib qolish) — keyinchalik boshqa joyga ko'chish qimmatga tushadigan holat. Postgres'da bu xavf boshqa ma'lumotlar bazalaridagidan kichik: ma'lumot standart Postgres formatida, pg_dump uni istalgan joyga olib chiqadi.

Lekin bog'lanish bazaning o'zida emas, atrofida paydo bo'ladi:

Amaliy qoida: provayder imkoniyatlaridan foydalaning, lekin muntazam pg_dump oling va uni boshqa joyda saqlang. Bu ham zaxira, ham "chiqish chiptasi".

7. O'zbekistonda saqlash talablari

Kurs o'quvchisi ilovasini O'zbekiston foydalanuvchilari uchun quradi. Shaxsiy ma'lumotlar haqidagi qonun (O'RQ-547, Analitika: foydalanuvchi xatti-harakatini o'lchash darsida tanishgan edik) ma'lumot qayerda saqlanishiga ham talab qo'yadi. 27-1-modda (2026-yil 26-martdagi O'RQ-1125 bilan o'zgartirilgan tahriri, lex.uz, 2026-10-26 da o'qildi) mazmuni qisqacha:

• Ba'zi toifalar — jismoniy shaxslarning biometrik va genetik ma'lumotlari hamda O'zbekistonda ishlaydigan telekommunikatsiya operatorlari xizmatidan foydalanuvchilar ma'lumotlari — O'zbekiston hududida saqlanishi shart.
• Boshqa shaxsiy ma'lumotlar chet elda ham saqlanishi mumkin, lekin qonunda sanalgan shartlardan biri bajarilishi kerak. Masalan, o'sha davlat teng himoyani ta'minlaydi deb tan olingan yoki vakolatli organ talablariga mos shartnoma qoidalari qabul qilingan.

Bu nimani anglatadi: vazifalar ro'yxatidagi email va ism bilan ishlaydigan ilova uchun chet eldagi managed Postgres qonunan mumkin bo'lishi mumkin, lekin shartlar bajarilganini tekshirish kerak. Yuz bilan kirish (biometrika) qo'shsangiz — o'sha ma'lumot O'zbekistondagi serverda bo'lishi shart. Bu yuridik maslahat emas: real loyihada qonunning amaldagi matnini lex.uz da o'qing va kerak bo'lsa yurist bilan maslahatlashing — tahrir 2026-yilda o'zgargani shuni ko'rsatadi.

8. Qanday tanlash

flowchart TD
  A{Kim boshqaradi?} -->|vaqt va bilim| S[VPS + Docker]
  A -->|kichik jamoa| B{Yuk qanday?}
  B -->|vaqti-vaqti, PR sinovi| N[Serverless: Neon]
  B -->|doimiy yuk| R[Klassik managed: RDS]
  B -->|auth va API ham kerak| P[Platforma: Supabase]

Diagramma — boshlang'ich yo'nalish, qat'iy qoida emas. Har variantda tekshiradigan savollar bir xil:

1. Zaxira muddati va PITR — qaysi tarifda, RPO qancha?
2. Ulanish limiti va pooler — ilovamiz modeliga sig'adimi?
3. Kerakli extension'lar va Postgres versiyasi bormi?
4. Server qaysi mintaqada, qonun talablariga mosmi?
5. Chiqish yo'li: pg_dump ga to'liq ruxsat bormi, hajm qancha?

9. Ko'p uchraydigan xatolar

10. Mashqlar

Mashqlar kurs/mashqlar/27/18-managed/ da. 2- va 3-mashq yechimlari Node 24 da tekshirilgan (biz ishga tushirdik).

1-mashq (oson): kim javob beradi

Managed Postgres'da quyidagilar uchun kim javobgar — "provayder" yoki "siz"?

• Diskning jismoniy buzilishi —
• WHERE siz UPDATE —
• Minor versiya tuzatishlari —
• vazifalar_api rolining huquqlari —
• Zaxiradan tiklab, ilova ishlashini tekshirish —

2-mashq (o'rta): ulanish byudjeti

ulanishSigadimi({ maxUlanish, zaxira, nusxalar, hovuzMax }) funksiyasi { kerak, bor, sigadi } qaytarsin: kerak = nusxalar × hovuzMax, bor = maxUlanish − zaxira (zaxira — admin va migratsiya uchun qoldirilgan ulanishlar). Ikki holatni tekshiring: kichik tarif (maxUlanish 100, zaxira 10, 4 nusxa × 20) va serverless (maxUlanish 100, zaxira 10, 150 funksiya nusxasi × 1).

function ulanishSigadimi({ maxUlanish, zaxira, nusxalar, hovuzMax }) {
  const kerak = nusxalar * hovuzMax;
  const bor = maxUlanish - zaxira;
  return { kerak, bor, sigadi: kerak <= bor };
}

console.log(ulanishSigadimi(
  { maxUlanish: 100, zaxira: 10, nusxalar: 4, hovuzMax: 20 }));
console.log(ulanishSigadimi(
  { maxUlanish: 100, zaxira: 10, nusxalar: 150, hovuzMax: 1 }));

{ kerak: 80, bor: 90, sigadi: true }
{ kerak: 150, bor: 90, sigadi: false }

3-mashq (qiyin): oylik xarajat (faraziy narxlar)

Ikki variantni taqqoslang. Narxlar faraziy — real provayder narxi emas, faqat hisob mantig'i uchun:

• VPS: oyiga 20 $ + administratorning oyiga 6 soat vaqti (soati 10 $).
• Serverless: compute soati 0.15 $, saqlash GB'i oyiga 0.35 $, administrator vaqti oyiga 1 soat. Baza 10 GB; compute kuniga 8 soat ishlaydi (qolgan vaqtda scale to zero), oy — 30 kun.

oylikNarx(variant) funksiyasi yozing va ikkala variantning narxini va arzonini chiqaring. Keyin serverless compute kuniga 24 soat ishlasa natija qanday o'zgarishini ko'ring.

function oylikNarx(v) {
  const compute = (v.computeSoat ?? 0) * (v.soatNarxi ?? 0);
  const saqlash = (v.gb ?? 0) * (v.gbNarxi ?? 0);
  const odam = v.adminSoat * v.adminNarxi;
  return (v.oylik ?? 0) + compute + saqlash + odam;
}

const vps = { oylik: 20, adminSoat: 6, adminNarxi: 10 };
const neonga = (soat) => ({
  computeSoat: soat * 30, soatNarxi: 0.15,
  gb: 10, gbNarxi: 0.35, adminSoat: 1, adminNarxi: 10,
});
for (const soat of [8, 24]) {
  const a = oylikNarx(vps);
  const b = oylikNarx(neonga(soat));
  const arzon = a < b ? "VPS" : "serverless";
  const matn = `VPS ${a} $, serverless ${b} $`;
  console.log(`${soat} soat: ${matn} — ${arzon}`);
}

8 soat: VPS 80 $, serverless 49.5 $ — serverless
24 soat: VPS 80 $, serverless 121.5 $ — VPS

11. Loyiha qadami: kanon tajribasi

Bu darsda vazifalar-api kodi o'zgarmaydi va commit yo'q — kanon hech qaysi provayderda hisob ochmadi. Lekin loyiha managed bazaga tayyor bo'lishi uchun nimalar allaqachon bor, sanab chiqamiz:

• Ulanish faqat DATABASE_URL orqali (26-qism) — provayder satrini qo'yish yetarli; parol kodda emas.
• RLS va SET LOCAL (Row Level Security) — transaction pooler bilan mos, oddiy SET emas.
• Extension'lar: pg_trgm, unaccent — keng tarqalgan, ko'p provayderlar ro'yxatida bor; buni tanlashdan oldin tekshirish kerak.
• Rollar (Rollar va huquqlar) — 106-rollar.sql superuser'siz ishlashi kerak; provayderda migratsiya roli bilan sinab ko'rish — o'quvchi ishi.
• Zaxira: provayderniki + o'z pg_dump (--globals-only cheklangan bo'lishi mumkin — rollarni migratsiya fayli qayta yaratadi).

Ikki manzil (pooler va to'g'ridan) Prisma bilan qanday ulanishini keyingi darslarda ko'ramiz: Prisma 7 da CLI manzili prisma.config.ts da, ilova manzili esa adapter'ga beriladigan hovuzda.

12. Real ishda

• Startaplarning katta qismi birinchi yillarda managed Postgres ishlatadi; o'sib, xarajat yoki talablar o'zgarganda o'z serveriga yoki boshqa provayderga ko'chadi — pg_dump shu yerda kerak.
• Neon branching CI'da: har pull request uchun alohida baza — zamonaviy jamoalarda tez tarqalayotgan naqsh.
• Intervyuda: "Managed baza tanlashda nimalarga qaraysiz?", "Serverless'da ulanish muammosi qanday hal qilinadi?", "Vendor lock-in Postgres'da qanchalik xavfli?"

Xulosa

• Provayder serverni boshqaradi, ma'lumotni emas: sxema, rollar va tiklash tekshiruvi — sizda.
• RDS — doim ishlaydigan instans, 0–35 kun zaxira; Neon — scale to zero va branching (tarix oynasi bilan cheklangan); Supabase — Postgres + tayyor xizmatlar.
• Ulanish limiti tarifga bog'liq: ilova — pooler orqali, migratsiya — to'g'ridan manzil.
• Superuser yo'q, extension ro'yxati cheklangan — tanlashdan oldin tekshiring.
• Lock-in bazada emas, atrofidagi xizmatlarda; muntazam pg_dump — chiqish chiptasi.
• O'zbekistonda biometrik, genetik va telekom foydalanuvchilari ma'lumoti mamlakat ichida saqlanishi shart (O'RQ-547, 27-1-modda).

Keyingi dars: ORM, query builder va raw SQL — SQL'ni qo'lda yozishdan tortib to'liq ORM'gacha: uch abstraksiya darajasi va ular orasidagi tanlov.

Manbalar

• AWS RDS — Introduction to backups; Backup retention period: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html, https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.BackupRetention.html
• Neon — Branching; Scale to zero: https://neon.com/docs/introduction/branching, https://neon.com/docs/introduction/scale-to-zero
• Neon — Connection pooling: https://neon.com/docs/connect/connection-pooling
• Supabase — Database backups; Extensions: https://supabase.com/docs/guides/platform/backups, https://supabase.com/docs/guides/database/extensions
• "Shaxsga doir ma'lumotlar to'g'risida"gi Qonun (O'RQ-547), 27-1-modda, O'RQ-1125 (26.03.2026) tahriri: https://lex.uz/docs/4396419
• Hammasi 2026-10-26 da o'qildi; provayderlar sinalmagan. Kanon bu dars uchun faqat hujjatga tayangan (hisob ochilmagan). Neon tarix oynasi (6 soat / 1 kun, 7 yoki 30 kungacha) 2026-10-27 da qayta tekshirildi. Biz ishga tushirdik (PostgreSQL 17.6, o'z klasterimiz): rolsuper, max_connections, pg_available_extensions soni; 2–3-mashqlar (Node 24).