A Cloudflare Hyperdrive egy nagyon konkrét és cseppet sem látványos probléma miatt létezik: egy Worker, amely 200 városban fut, és egyetlen városban álló, egyetlen Postgres adatbázissal beszélget, lassabb, mint ugyanaz a lekérdezés egy olyan szerverről, amely közvetlenül az adatbázis mellett áll. Nem egy kicsit lassabb. Gyakran többszörösen lassabb, méghozzá olyan okokból, amelyeknek semmi közük ahhoz, hogyan van megírva a lekérdezés.
Amikor egy serverless alkalmazás vontatottnak tűnik, az első ösztön az, hogy a lekérdezéstervezőt hibáztatjuk, vagy felveszünk egy indexet. Regionális adatbázissal beszélgető Workers esetén a lekérdezéssel általában semmi baj nincs. A kapcsolat a probléma.
Amit a Hyperdrive valóban megold: az adatbázis-kapcsolat felépítésének költségét, amit minden egyes kérésnél újra ki kell fizetni. Egy Postgres kapcsolathoz kell egy TCP kézfogás, egy TLS egyeztetés és egy hitelesítési váltás, még mielőtt egyetlen sor is megmozdulna, és mindegyik lépés egy oda-vissza út onnan, ahol a Worker felébredt, oda, ahol az adatbázis él. A Hyperdrive meleg kapcsolatokat tart fenn az adatbázisod közelében és készletbe szervezi őket, így a Worker egy már nyitott kapcsolatot vesz kölcsön ahelyett, hogy újat építene.
Miért lassú a Postgreshez közvetlenül kapcsolódó Worker
Egy hagyományos alkalmazásszerver induláskor egyszer nyit egy kapcsolatkészletet, és a folyamat teljes élettartama alatt újrahasznosítja. A kézfogás költségét induláskor fizeti ki, aztán elosztja több millió kérés között, amíg valaki újra nem indítja a szolgáltatást.
A Workers nem így működik. Minden egyes futás rövid életű, és a Cloudflare bármelyik helyszínén elindulhat. Nincs hosszú életű folyamat, amely készletet tartana, így segítség nélkül minden kérés kifizeti a teljes felépítési költséget, méghozzá azon a távolságon, amely a peremet elválasztja az origin adatbázisodtól.
Három oda-vissza út az első adatbájt előtt nem hangolási kérdés. Egy sydney-i felhasználó, aki egy londoni Postgresszel beszélgető Workert szólít meg, négyszeresen fizeti meg ezt a késleltetést: TCP, aztán TLS, aztán hitelesítés, aztán végre a lekérdezés. Maga a lekérdezés talán két ezredmásodperc.
Van egy második, csendesebb hibamód is. A Postgres kapcsolatonként külön backend folyamatot foglal, és a maximuma véges, jellemzően néhány száz. Az a Worker, amely több ezer párhuzamos futásra skálázódik, kimeríti ezt a készletet, és pontosan abban a forgalmi csúcsban kezd elutasított kapcsolatokat gyűjteni, amelyre a peremet építetted.
Mit tesz ez ellen a Hyperdrive
A Hyperdrive a Worker és az adatbázis közé ül be kapcsolatkészletezőként, amelyet a Cloudflare üzemeltet helyetted. Meleg kapcsolatokat tart nyitva az originod felé, így egy futás kölcsönvesz egyet ahelyett, hogy a nulláról egyeztetne újat.
A lekérdezések eredményét is gyorsítótárazza. Az ismétlődő olvasások kiszolgálhatók anélkül, hogy egyáltalán hozzáérnének az originhez, ami a forgalom érdemi részénél késleltetési kérdésből találati arány kérdésévé alakítja a dolgot. Az írások és minden nem determinisztikus művelet közvetlenül átmegy.
A konfiguráció egyetlen kapcsolati sztring. Regisztrálod az adatbázist a Cloudflare-nél, kapsz egy Hyperdrive bindingot, és a meglévő Postgres illesztőprogramodat erre a bindingra irányítod az adatbázis helyett. Az illesztőprogram, az SQL és a séma nem változik. Ez többet nyom a latban, mint amilyennek hangzik, mert azt jelenti, hogy a változtatás visszafordítható, és bármit is átírni nem kell ahhoz, hogy közvetlen kapcsolathoz mérd.
A számok, amelyek eldöntik, hogy illik-e hozzád
A Cloudflare dokumentációjához mérve 2026 augusztusában ellenőrizve, és érdemes újra megnézni, mielőtt elköteleződsz, mert ezek az értékek mozognak.
| Workers Free | Workers Paid | |
|---|---|---|
| Költség | Benne van | Benne van |
| Lekérdezések | 100 000 naponta | Korlátlan |
| Konfigurált adatbázisok | 10 fiókonként | 25 fiókonként |
| Origin kapcsolatok konfigurációnként | nagyjából 20 | nagyjából 100 |
| Lekérdezés maximális hossza | 60 másodperc | 60 másodperc |
| Gyorsítótárazott válasz mérete | 50 MB | 50 MB |
A Hyperdrive egyik csomagban sem jár külön díjjal , és nincsenek egress díjak sem. Az, hogy mi számít lekérdezésnek, tágan van meghatározva: egy select, egy insert, egy update, egy delete vagy egy sémamódosítás mind beleszámít, és a gyorsítótárból kiszolgált lekérdezések ugyanúgy számítanak, mint a többiek. Az ingyenes napi keret UTC szerint éjfélkor nullázódik.
A korlátokat leíró dokumentáció 15 másodperces kezdeti kapcsolódási időkorlátot és 10 perces tétlenségi időkorlátot említ. A lekérdezésenkénti 60 másodperces plafon az, ami elkapja a riportolási terhelést átköltöztető csapatokat: egy analitikus lekérdezés, amely ütemezett feladatként két percig fut, itt egyszerűen elhasal.
Milyen adatbázisok működnek valóban
A Hyperdrive támogatja a PostgreSQL 9.0 és 17.x közötti, valamint a MySQL 5.7 és 8.x közötti verzióit , akár saját üzemeltetésben, akár menedzselt formában. A MariaDB a MySQL kompatibilitás alá esik.
A név szerint említett menedzselt szolgáltatók között ott van az AWS Aurora mind a Postgres, mind a MySQL kompatibilis formájában, a Neon, a Supabase, a Timescale, a Materialize, a CockroachDB és a PlanetScale. Az Azure és a Google Cloud menedzselt példányai szintén működnek.
A gyakorlati korlát nem a motor, hanem az elérhetőség. Az adatbázisodnak megcímezhetőnek kell lennie a Cloudflare hálózatából. Egy privát VPC-be zárt, nyilvános végpont nélküli Postgres példányhoz alagút vagy peering megállapodás kell ahhoz, hogy a Hyperdrive egyáltalán lássa, és ez hálózati projekt, nem konfigurációs módosítás.
Mikor rossz válasz a Cloudflare Hyperdrive
Amikor az adat helye a peremen van. Ha a hozzáférési mintád kulcs-érték kikeresés, a Workers KV gyorsabb és egyszerűbb. Ha kis relációs adatbázist szeretnél, amely a Worker közelében él, nem pedig egyetlen régióban, akkor a D1 az erre tervezett termék. A Hyperdrive arra az esetre való, amikor már van Postgresed vagy MySQL-ed, és meg is akarod tartani.
Amikor a terhelés analitikus. A 60 másodperces plafon és a lekérdezésenkénti elszámolás a tranzakciós forgalomhoz illik. A hosszú aggregációk helye egy olyan feladatfuttatón van, amely közvetlenül beszél az adatbázissal.
Amikor nem mértél. A leggyakoribb kudarc az, amikor egy csapat olyan alkalmazáshoz ad Hyperdrive-ot, amely soha nem volt kapcsolatkorlátos. Ha egy Worker azért lassú, mert hat egymás utáni lekérdezést indít ott, ahol egy is elég lenne, akkor ennek a hat kapcsolatnak a készletezése csak hajszálnyival teszi kevésbé lassúvá, a tényleges problémát pedig érintetlenül hagyja.
Ezt a mérést érdemes rendesen elvégezni minden más előtt. A Cloudflare Workers és az AWS Lambda összehasonlításunk bemutatja, hol nyer valóban a peremen futtatás, a Cloudflare D1 pedig azt az esetet tárgyalja, amikor az adatbázis áthelyezése többet ér, mint az odavezető út gyorsítása.
Hogyan hozd meg jól a döntést
Mérd meg egy kérés teljes idejét közvetlen kapcsolaton, majd újra a Hyperdrive-on keresztül, olyan helyről, amely messze van az adatbázisodtól. Ha a különbség kicsi, a késleltetésed máshol lakik, és megspóroltál magadnak egy függőséget. Ha a különbség nagy, valódi pénzt találtál.
A Mecanik peremarchitektúrákat épít és vizsgál felül a szoftverfejlesztési csapatán keresztül, beleértve azt a látványtalan részt is, amikor valaki megméri, mi lassú valójában, mielőtt bármit is újraterveznénk. Ha a serverless alkalmazásod lassabb, mint a szerver, amelyet leváltott, a kapcsolati útvonal az első hely, ahová érdemes benézni.
További olvasnivaló: Cloudflare Workers API építése: serverless útmutató 2026 , Cloudflare Queues: háttérfeladatok a peremen , LLM-késleltetés csökkentése: caching és edge stratégiák és Hogyan fejlesszünk webalkalmazást 2026-ban .
Gyakran ismételt kérdések
Milyen problémát old meg a Cloudflare Hyperdrive? Az adatbázis-kapcsolat megnyitásának költségét minden egyes kérésnél. Egy Worker rövid életű, és nem tart kapcsolatkészletet, így Hyperdrive nélkül minden futás kifizet egy TCP kézfogást, egy TLS egyeztetést és egy hitelesítési váltást azon a távolságon, amely a peremet az adatbázisodtól elválasztja, még mielőtt bármilyen adat megmozdulna. A Hyperdrive meleg, készletezett kapcsolatokat tart az origin közelében, így a Worker inkább kölcsönvesz egyet.
Mennyibe kerül a Cloudflare Hyperdrive? A Workers csomagodon felül semmibe. Mind a Free, mind a Paid csomagban benne van, külön díj és egress költség nélkül. A Free csomag napi 100 000 adatbázis-lekérdezést enged, ami UTC szerint éjfélkor nullázódik, a Paid csomag pedig korlátlan. A select, insert, update, delete és a sémamódosítások mind lekérdezésnek számítanak, és a gyorsítótárból kiszolgált lekérdezések ugyanannyit számítanak, mint a többiek.
Milyen adatbázisokat támogat a Hyperdrive? A PostgreSQL 9.0 és 17.x közötti, valamint a MySQL 5.7 és 8.x közötti verzióit, saját üzemeltetésben vagy menedzselten, a MariaDB pedig a MySQL kompatibilitás alá esik. A név szerint említett szolgáltatók között van az AWS Aurora, a Neon, a Supabase, a Timescale, a Materialize, a CockroachDB és a PlanetScale, valamint az Azure és a Google Cloud menedzselt példányai. Az adatbázisnak elérhetőnek kell lennie a Cloudflare hálózatából.
Mik a Hyperdrive legfontosabb korlátai? Fiókonként tíz konfigurált adatbázis a Free csomagban és 25 a Paid csomagban, konfigurációnként nagyjából 20 origin kapcsolat a Free csomagban és 100 a Paid csomagban, 60 másodperces maximális lekérdezési idő, 50 MB gyorsítótárazott válaszméret, 15 másodperces kezdeti kapcsolódási időkorlát és 10 perces tétlenségi időkorlát. A lekérdezésenkénti 60 másodperces plafon az, ami az analitikus terheléseket blokkolja.
A Hyperdrive-ot vagy a D1-et használjam? A Hyperdrive-ot akkor, ha már van Postgres vagy MySQL adatbázisod, amelyet meg akarsz tartani, és a gond az elérésének késleltetése. A D1-et akkor, ha eleve olyan relációs adatbázist szeretnél, amely a Cloudflare hálózatában él. Két különböző problémát oldanak meg: az egyik felgyorsítja az utat egy meglévő adatbázishoz, a másik megszünteti a távolságot azzal, hogy elmozdítja az adatot.
Hozzászólások