Cloudflare Hyperdrive există din cauza unei probleme concrete și deloc spectaculoase: un Worker care rulează în 200 de orașe și vorbește cu o singură bază de date Postgres dintr-un singur oraș este mai lent decât aceeași interogare pornită de pe un server aflat chiar lângă acea bază de date. Nu puțin mai lent. Adesea de câteva ori mai lent, și din motive care nu au nimic de-a face cu felul în care este scrisă interogarea.
Instinctul, când o aplicație serverless pare greoaie, este să dai vina pe planificatorul de interogări sau să adaugi un index. Pe Workers care vorbesc cu o bază de date regională, interogarea este de obicei în regulă. Conexiunea este problema.
Ce rezolvă de fapt Hyperdrive: costul stabilirii unei conexiuni la baza de date, plătit la fiecare cerere în parte. O conexiune Postgres are nevoie de un handshake TCP, de o negociere TLS și de un schimb de autentificare înainte să se miște un singur rând, iar fiecare dintre acești pași este un drum dus-întors de acolo de unde s-a trezit Worker-ul până acolo unde trăiește baza de date. Hyperdrive ține conexiuni calde aproape de baza ta de date și le grupează într-un pool, astfel încât Worker-ul împrumută o conexiune deschisă în loc să construiască una nouă.
De ce un Worker conectat direct la Postgres este lent
Un server de aplicație clasic deschide un pool de conexiuni o singură dată, la pornire, și le refolosește pe toată durata de viață a procesului. Costul handshake-ului se plătește la pornire și se împrăștie apoi peste milioane de cereri, până când cineva repornește serviciul.
Workers nu funcționează așa. Fiecare invocare este scurtă și poate rula în oricare dintre locațiile Cloudflare. Nu există un proces de lungă durată care să țină un pool, așa că, fără ajutor, fiecare cerere plătește integral costul de inițiere, iar acest cost se plătește pe distanța dintre edge și baza ta de date de origine.
Trei drumuri dus-întors înainte de primul octet de date nu sunt o problemă de tuning. Un utilizator din Sydney care lovește un Worker ce vorbește cu Postgres la Londra plătește acea latență de patru ori: TCP, apoi TLS, apoi autentificare, apoi în sfârșit interogarea. Interogarea în sine durează poate două milisecunde.
Mai există un mod de eșec, mai discret. Postgres alocă un proces backend pentru fiecare conexiune, iar maximul lui este finit, de regulă câteva sute. Un Worker care scalează la mii de invocări simultane va epuiza acel pool și va începe să adune conexiuni refuzate exact în vârful de trafic pentru care ai construit edge-ul.
Ce face Hyperdrive în privința asta
Hyperdrive stă între Worker și baza de date ca un connection pooler pe care Cloudflare îl operează în numele tău. Menține conexiuni calde către originea ta, așa că o invocare împrumută una în loc să negocieze una nouă de la zero.
De asemenea, pune în cache rezultatele interogărilor. Citirile care se repetă pot fi servite fără să atingă deloc originea, ceea ce transformă o problemă de latență într-o problemă de rată de cache pentru o parte însemnată din trafic. Scrierile și tot ce este nedeterminist trec direct.
Configurarea înseamnă un connection string. Înregistrezi baza de date la Cloudflare, primești un binding Hyperdrive și îndrepți driverul Postgres existent către acel binding în loc de baza de date. Driverul, SQL-ul și schema nu se schimbă. Asta contează mai mult decât pare, pentru că înseamnă că schimbarea este reversibilă și o poți măsura față de o conexiune directă fără să rescrii nimic.
Cifrele care decid dacă ți se potrivește
Verificate în documentația Cloudflare în august 2026 și de reverificat înainte să te angajezi, pentru că se schimbă.
| Workers Free | Workers Paid | |
|---|---|---|
| Cost | Inclus | Inclus |
| Interogări | 100.000 pe zi | Nelimitat |
| Baze de date configurate | 10 pe cont | 25 pe cont |
| Conexiuni la origine per configurație | aproximativ 20 | aproximativ 100 |
| Durata maximă a unei interogări | 60 de secunde | 60 de secunde |
| Dimensiunea răspunsului din cache | 50 MB | 50 MB |
Hyperdrive nu aduce niciun cost suplimentar pe niciunul dintre planuri și nu are taxe de egress. Ce se socotește drept interogare este definit larg: un select, un insert, un update, un delete sau o modificare de schemă se numără toate, iar interogările servite din cache se numără la fel ca cele necachate. Alocația zilnică gratuită se resetează la miezul nopții UTC.
Documentația limitelor menționează un timeout de 15 secunde pentru conexiunea inițială și un timeout de inactivitate de 10 minute. Plafonul de 60 de secunde pe interogare este cel care prinde pe picior greșit echipele care mută un volum de raportare: o interogare analitică ce durează două minute într-un cron job pur și simplu va eșua aici.
Ce baze de date funcționează cu adevărat
Hyperdrive acceptă PostgreSQL de la 9.0 la 17.x și MySQL de la 5.7 la 8.x , găzduite de tine sau administrate. MariaDB intră sub compatibilitatea MySQL.
Printre furnizorii administrați menționați pe nume se află AWS Aurora în ambele variante, compatibilă cu Postgres și cu MySQL, apoi Neon, Supabase, Timescale, Materialize, CockroachDB și PlanetScale. Funcționează și instanțele administrate pe Azure și pe Google Cloud.
Constrângerea practică nu este motorul, ci accesibilitatea. Baza ta de date trebuie să fie adresabilă din rețeaua Cloudflare. O instanță Postgres închisă într-un VPC privat, fără endpoint public, are nevoie de un tunel sau de un aranjament de peering înainte ca Hyperdrive să o poată vedea măcar, iar asta este un proiect de rețea, nu o schimbare de configurație.
Când Cloudflare Hyperdrive este răspunsul greșit
Când datele trebuie să stea la edge. Dacă tiparul tău de acces înseamnă căutări cheie-valoare, Workers KV este mai rapid și mai simplu. Dacă vrei o bază de date relațională mică, aflată lângă Worker în loc de o singură regiune, D1 este produsul gândit pentru asta. Hyperdrive este pentru situația în care ai deja Postgres sau MySQL și vrei să le păstrezi.
Când volumul de lucru este analitic. Plafonul de 60 de secunde și contorizarea pe interogare se potrivesc traficului tranzacțional. Agregările lungi își au locul pe un job runner care vorbește direct cu baza de date.
Când nu ai măsurat. Eșecul pe care îl vedem cel mai des este o echipă care adaugă Hyperdrive unei aplicații ce nu a fost niciodată limitată de conexiuni. Dacă un Worker este lent pentru că face șase interogări secvențiale acolo unde una ar fi de ajuns, punerea acelor șase conexiuni într-un pool îl face marginal mai puțin lent și lasă problema reală neatinsă.
Măsurătoarea aceea merită făcută ca la carte înaintea oricărui alt pas. Comparația noastră între Cloudflare Workers și AWS Lambda arată unde câștigă cu adevărat execuția la edge, iar Cloudflare D1 acoperă cazul în care mutarea bazei de date bate accelerarea drumului până la ea.
Cum iei decizia corectă
Cronometrează o cerere cap-coadă pe o conexiune directă, apoi din nou prin Hyperdrive, dintr-o locație aflată departe de baza ta de date. Dacă diferența este mică, latența ta stă în altă parte și tocmai ți-ai economisit o dependență. Dacă diferența este mare, ai găsit bani adevărați.
Mecanik construiește și revizuiește arhitecturi edge prin echipa noastră de dezvoltare software , inclusiv partea nespectaculoasă în care cineva măsoară ce este cu adevărat lent înainte să se rearhitectureze ceva. Dacă aplicația ta serverless este mai lentă decât serverul pe care l-a înlocuit, calea conexiunii este primul loc unde trebuie să te uiți.
Lecturi suplimentare: Creează un API Cloudflare Workers: ghid serverless 2026 , Cloudflare Queues: joburi de fundal la edge , Cum să reduci latența LLM: strategii de caching și edge și Cum să construiești o aplicație web în 2026 .
Întrebări frecvente
Ce problemă rezolvă Cloudflare Hyperdrive? Costul deschiderii unei conexiuni la baza de date la fiecare cerere. Un Worker are viață scurtă și nu ține niciun pool de conexiuni, așa că, fără Hyperdrive, fiecare invocare plătește un handshake TCP, o negociere TLS și un schimb de autentificare pe distanța dintre edge și baza ta de date, înainte să se miște vreun octet de date. Hyperdrive ține conexiuni calde, grupate într-un pool, aproape de origine, astfel încât Worker-ul împrumută una.
Cât costă Cloudflare Hyperdrive? Nimic peste planul tău Workers. Este inclus atât în planul Free, cât și în cel Paid, fără taxă separată și fără costuri de egress. Planul Free permite 100.000 de interogări la baza de date pe zi, cu resetare la miezul nopții UTC, iar planul Paid este nelimitat. Select, insert, update, delete și modificările de schemă se numără toate ca interogări, iar interogările din cache se numără la fel ca cele necachate.
Ce baze de date acceptă Hyperdrive? PostgreSQL de la 9.0 la 17.x și MySQL de la 5.7 la 8.x, găzduite de tine sau administrate, MariaDB fiind acoperită de compatibilitatea MySQL. Printre furnizorii menționați se află AWS Aurora, Neon, Supabase, Timescale, Materialize, CockroachDB și PlanetScale, plus instanțele administrate pe Azure și Google Cloud. Baza de date trebuie să fie accesibilă din rețeaua Cloudflare.
Care sunt principalele limite ale Hyperdrive? Zece baze de date configurate per cont pe Free și 25 pe Paid, aproximativ 20 de conexiuni la origine per configurație pe Free și 100 pe Paid, o durată maximă a interogării de 60 de secunde, un răspuns din cache de 50 MB, un timeout de 15 secunde pentru conexiunea inițială și un timeout de inactivitate de 10 minute. Plafonul de 60 de secunde pe interogare este cel care blochează volumele analitice.
Să folosesc Hyperdrive sau D1? Hyperdrive atunci când ai deja o bază de date Postgres sau MySQL pe care vrei să o păstrezi și problema este latența ajungerii la ea. D1 atunci când vrei o bază de date relațională care trăiește din start în rețeaua Cloudflare. Rezolvă probleme diferite: unul accelerează drumul către o bază de date existentă, celălalt elimină distanța mutând datele.
Comentarii