Miért Cloudflare-stackre építünk minden új projektet?

Három éve a stackünk standard volt: Next.js Vercelen, PostgreSQL Supabasen, Redis Upstash-ben, R2 helyett S3. Működött. De minden projekt elején újra kellett magyarázni az ügyfélnek hogy „nem, ez nem egy szolgáltató, ez négy, itt a négy különálló számla”.

Ma minden új KKV projekt Cloudflare-en fut: Workers + D1 + R2 + KV + Durable Objects. Egy számla. Egy konzol. Egy support csatorna.

A három előny ami eldöntötte

1. Cold start nincs

A Workers V8 isolate alapú, nem konténer. Ez azt jelenti, hogy az első request 5ms-en belül válaszol. Vercel serverless function-nél ugyanez 800-1500ms volt egy KKV trafficon. Nem azért lett gyorsabb a site, mert jobb kódot írunk, hanem mert a platform alatta más.

2. Edge-first deploy globálisan

300+ city, beleértve Budapestet is. A magyar KKV-k 90%-ának nincs nemzetközi forgalma, de a budapesti edge azt jelenti, hogy a látogató kérése sosem megy ki az országból. Adatvédelmileg is tisztább.

3. D1 + R2 megöli az infrastruktúra-bonyolultságot

D1 = SQLite a peremen. Kis-közepes KKV adatmennyiségnél (értsd: pár GB) nincs értelme dedicated Postgres-t üzemeltetni. R2 = S3-kompatibilis object storage, egress költség nélkül. Egy középes webshop képei korábban havi 30-40 USD bandwidth-et fogyasztottak. R2-n nulla.

Mit nem szeretünk benne

• Workers runtime nem teljes Node, fs, native módulok, hosszú futású folyamatok nincsenek. Át kellett írnunk pár csomagot Workers-kompatibilisre.
• D1 még nem érett az írásintenzív analytics-ra. Ha napi 100 000+ rekordot írsz, nézz Hyperdrive-ot vagy külön Postgres-t.
• Durable Objects jó, de a tanulási görbéje meredek. Az első projektben még simán megoldhatod KV + cron-nal.

Mikor NEM ezt javaslom

Ha a meglévő infrastruktúrátok Postgres-re épül (pl. Hasura, Prisma + heavy joins, geo lekérdezések), akkor ne migrálj rá kényszerből. Az új zöldmezős projektek profitálnak a legtöbbet ebből.

A konkrét stack amit használunk

Frontend: Next.js 16 (App Router) + React 19
Adapter:  @opennextjs/cloudflare
Backend:  Workers (Hono) vagy Server Actions
DB:       D1 (SQLite) + Drizzle ORM
Storage:  R2 (object) + KV (cache, session)
Realtime: Durable Objects (rare) vagy ws stream
Auth:     Auth.js v5 + D1 adapter
Monitor:  Workers Analytics Engine + Sentry

Ezt a stacket egy KKV projekt 2-3 hét alatt élesre tudjuk vinni, feltéve hogy az ügyfél döntéseket hoz, nem szeretnénk meeting-eken újra-iterálni a wireframe-eket.