2026. május 8. · #hyperdrive #postgresql #tutorial #cloudflare #developer

Hyperdrive PG-pool: Supabase 100-conn-limit megoldva CF-edge-en

Ha PostgreSQL-t használsz (Supabase, Neon, RDS) és belefutottál a connection-limit problémába: a Cloudflare Hyperdrive a megoldás. Edge-pool, query-cache, <5 ms overhead — magyar UI.

A PostgreSQL connection-limit klasszikus fájdalmat okoz minden modern serverless-fejlesztőnek. A Supabase free-tier 60 conn-nal, a Neon 100 conn-nal, az RDS db.t3.medium 150 conn-nal indul. Ha a CF Workered 5000 párhuzamos request-et fogad, és mindegyik új PG-kapcsolatot akar nyitni — csődöt mond a DB fél-percen belül. A /app/hyperdrive plugin ezt oldja meg. Ebben a posztban arról, mit csinál, hogyan működik, és mi a setup.

⚠️ A klasszikus probléma

Worker-environment-ben:

import { Pool } from "pg";

const pool = new Pool({
  host: "db.example.com",
  user: "myuser",
  password: env.DB_PASSWORD,
});

export default {
  async fetch(request, env) {
    const result = await pool.query("SELECT * FROM users WHERE id = $1", [123]);
    return Response.json(result.rows);
  }
};

A probléma:

❌ Cold-start: minden új Worker-instance új connection-t nyit
❌ Globális verseny: 100 Worker-instance = 100 conn → DB-limit
❌ Latency: a Worker → DB kapcsolat TLS-handshake-tel ~200 ms
💰 Költség: a DB-szolgáltató per-conn számláz

⚠️ A megoldás “klasszikusan”: PgBouncer vagy Supabase Pooler — de ezek regionálisak (egy data-center-ben futnak), és nem edge-en.

💡 A Hyperdrive megoldása

A Cloudflare Hyperdrive egy globális PG-pool, ami a CF-edge-en fut:

flowchart LR
    W1[Worker 1] --> HD[Hyperdrive edge-pool]
    W2[Worker 2] --> HD
    W3[Worker N] --> HD
    HD -->|aggregált 5-10 conn| DB[(Te DB-d<br/>Supabase/Neon/RDS)]
    HD -.->|cache hit| C[(Query Cache)]

Mit csinál?

✅ Aggregál: 100 Worker → 5-10 tényleges DB-conn
⚡ Cache-el: ismétlődő SELECT-ek a cache-ből jönnek (millisecond-osan)
🌍 Routing: a magyar felhasználói query → a legközelebbi Hyperdrive-pool → regionális DB
🔒 Encrypted tunnel: TLS a Hyperdrive és a saját DB-d között

Eredmény:

✅ 5-10 ms overhead minden Worker-hívásra (cold-start nélkül)

✅ 100+ Worker → 5-10 DB-conn ratio

⚡ 2-5× gyorsabb ismétlődő query (cache-hit)

🎯 A DB-szolgáltató boldog — kevesebb kapcsolat

🎨 A `/app/hyperdrive` UI

Magyar UI-on:

[itt screenshot — Hyperdrive konfig-mezők]

Új konfiguráció gomb
Beírod a DB-credentials:
- Host (pl. db.supabase.co)
- Port (5432)
- Database név
- User
- Password (titkosan tárolva)
Cache-policy:
- disabled — nincs cache
- enabled — minden SELECT cache-elve (60 mp default)
- custom-ttl — pontos TTL beállítás
Mentés → kapsz egy Hyperdrive connection string-et:
```
postgresql://user:[email protected]:5432/dbname
```

✅ Ezt a connection string-et használd a kódodban a saját DB-host helyett. Egy sor cserélődik, és a 100-conn-limit megszűnt.

📝 Példa — Astro 5 + Supabase + Hyperdrive

Klasszikus Astro 5 + Supabase setup:

// src/lib/db.ts (a régi)
import postgres from "postgres";

const sql = postgres(
  "postgresql://user:[email protected]:5432/postgres"
);

export { sql };

Hyperdrive-szal:

// src/lib/db.ts (az új)
import postgres from "postgres";

const sql = postgres(
  process.env.HYPERDRIVE_URL  // a CF Hyperdrive connection string
);

export { sql };

Astro-build idején és Worker-runtime-ban is a Hyperdrive felé megy a kapcsolat. A Supabase-szerver onnan kapja az aggregált connection-eket.

A wrangler.toml-ban:

[[hyperdrive]]
binding = "DB"
id = "abc123def456"  # A PromNET UI-n megjelenik a config-id

[vars]
HYPERDRIVE_URL = "postgresql://hd-abc123.cloudflare-hyperdrive.com:5432/postgres"

⚡ A Query-cache — mire jó?

A Hyperdrive alapból cache-eli az ismétlődő SELECT-eket. Például:

SELECT name FROM products WHERE category = 'electronics' LIMIT 20;

Ez valószínűleg a webshopod front-page-én fut, minden látogatónál. Hyperdrive-cache-szel:

🐢 Első kérés → DB-hez megy (~50 ms)
⚡ 2. - 60. másodpercbeli kérések → cache-ből (~5 ms)
🔄 60 mp után → DB-hez újra (cache lejárt)

✅ Eredmény: ha napi 10 ezer látogatód van, és mindegyik 1 SELECT-et hív, az 10.000 → ~600 DB-query a 60 mp-es cache-szel. 94% csökkentés.

A TTL állítható:

0 — nincs cache
60 (default) — 1 perc
300 — 5 perc
3600 — 1 óra
86400 — 1 nap

💡 Statikus ár-listáknál, kategória-listáknál, CMS-tartalmaknál hosszú TTL nagyon hatékony.

⚠️ Mire NE használj cache-et?

Query	Cache OK?
✅ `SELECT * FROM products WHERE category = 'X'`	Igen (60 mp)
⚠️ `SELECT * FROM users WHERE id = $1`	Igen (rövid TTL, 5 mp)
❌ `SELECT COUNT(*) FROM orders WHERE date = TODAY`	NEM — élő counter
❌ `SELECT * FROM stock WHERE product_id = $1`	NEM — élő stock
❌ `SELECT user_balance FROM accounts WHERE id = $1`	NEM — élő pénz

⚠️ A szabály: ha az érték másodpercen belül változhat és számít, ne cache-eld.

🔒 Adatvédelem

A Hyperdrive a CF-edge-en fut, európai régiókban. A DB-credentials titkosan tárolódnak a CF Vault-ban. A query-cache szintén EU-n belül marad.

🇭🇺 A magyar GDPR-megfelelőség alapból teljesül, ha a saját DB-d is EU-régióban van (Supabase EU, Neon EU, RDS Frankfurt).

💰 A Pricing

A CF Hyperdrive ingyenes a CF-Workers-Paid-csomagban (havi 5 USD). Workers Free-en is használható, napi 100k operationig.

A PromNET-en:

Tétel	Költség
💰 Hyperdrive-alap	0 — beépítve a fiókodba
💰 Query-throughput (1M op/hó fölött)	0.4 USD / 1M
💰 Query-cache-storage	0.05 USD / GB / hó

✅ Egy átlag-magyar SaaS-app (havi 100k user, mindegyik 50 query) 5M op / hó = 2 USD / hó. A teljes Supabase-cost-ot is csökkenti mert kevesebb DB-conn kell.

🇭🇺 Esettanulmány — egy magyar SaaS

Tényleges példa: HR-onboarding-platform, Supabase Pro (25 USD/hó, 200 conn-limit), Cloudflare Workers (Paid, 5 USD/hó).

Elő-Hyperdrive:

❌ Csúcsidőben 200 conn-limit hit, error-rate ~5%
❌ Felhasználók “DB-error” üzenetet kapnak
💰 Kell upgrade Supabase Team-csomagra (599 USD/hó!)

Post-Hyperdrive:

✅ Csúcsidőben maximum 30 conn él (a 200-ból 15%)
✅ Error-rate 0%
✅ Marad Pro-csomagon (25 USD/hó)
💰 Megtakarítás: 574 USD / hó = ~210.000 Ft / hó

⚡ Időbefektetés a Hyperdrive-setupra: 20 perc. ROI: percek alatt.

❌ Mire NEM jó?

A Hyperdrive NEM:

❌ Saját DB-szerver helyettesítője — magát a DB-t futtatnod kell (Supabase, Neon, RDS). A Hyperdrive csak a poolt és cache-et adja
❌ MySQL-támogatás — egyelőre csak PostgreSQL. MySQL/MariaDB roadmapen, de 2026 végéig nem ígérhető
⚠️ Write-heavy load-on segít — a write-queryket nem cache-eli, és a write-conn-okat nem aggregálja olyan mértékben mint a read-conn-t. Ha az app-od >30% write, a megtakarítás kisebb

✅ Mire IDEÁLIS?

✅ Read-heavy webshop — termékek, kategóriák, blog, CMS
✅ Multi-tenant SaaS — sok-felhasználó, mindenki ugyanazt a read-pattern-t fut
✅ Edge-deployed app — Astro 5 SSR, Next.js Edge, SvelteKit Cloudflare adapter
✅ Magas-load workshop — peak-idős traffic-ben

🚀 Hogyan kezdj?

DB-credentials kéznél (Supabase / Neon / RDS hostname, user, jelszó)
/app/hyperdrive/uj → új konfiguráció
5-perces setup — a UI vezet végig
Connection string cserélés a kódodban
Deploy és monitorozás — a /app/hyperdrive/<id>/stats oldalon látod a query-throughput-ot, cache-hit-rate-et, conn-pool-state-et

🔮 Mi jön ezután?

Q2 2026 — MySQL-támogatás
Q2 2026 — Replica-routing (read-replica-jelzés)
Q3 2026 — Query-analyzer (lassú queryk azonosítása)
Q4 2026 — Cross-region failover

🎯 Próbáld ki

/app/hyperdrive — ingyenes setup, 20 perc és 0 conn-limit-error lesz a logodban. Kérdés: /community/dev vagy /app/support.

Polyák Csaba