D1 de la Cloudflare: cum scalează milioane de baze de date SQLite

Cloudflare explică în detaliu cum planul de control D1 scalează la milioane de baze de date SQLite, cu o creștere de 15x a bazelor active în ultimul an. Trucul arhitectural: separarea strictă între planul de date, care rămâne la edge, și planul de control, unde latența centralizată e acceptabilă. Fiecare bază e susținută de un Durable Object.

De ce modelul vechi de bază de date nu mai ține

Arhitectura tradițională presupune unul sau două clustere mari de baze de date per aplicație, plus un pool de conexiuni care să gestioneze accesul. Modelul a funcționat ani buni, dar dezvoltarea asistată de AI și platformele de vibe coding l-au răsturnat. Aplicațiile se îndreaptă acum spre multe baze de date mici: una per utilizator, per aplicație, per mediu de preview sau per tenant.

Pentru D1, baza de date serverless administrată de Cloudflare, construită pe SQLite, acest model se potrivește natural. Poți crea milioane de baze de date și plătești doar pentru ce folosești. Problema reală nu e crearea, ci scalarea planului de control fără ca fiecare interogare să treacă prin gâturi de sticlă centralizate.

Cloudflare a publicat un deep dive despre arhitectura planului de control D1, iar cifrele din material sunt concrete: 15x creștere a numărului de baze de date active în ultimul an și 65x în ultimii doi ani, măsurat la 8 octombrie 2026. Numărul de baze de date active zilnic a crescut de 18 ori în ultimul an. Sursa: Cloudflare Blog.

Principiile care ghidează arhitectura

Cloudflare enumeră câteva principii de inginerie care au stat la baza deciziilor. Sunt generice și se aplică oricui construiește sisteme similare:

• Proiectează toate procesele cu eșec și idempotență în minte. Eșecurile se întâmplă, sistemul trebuie să se autocorecteze și să continue.
• Evită componentele centralizate într-o singură regiune pe orice cale critică pentru planul de date.
• Folosește Workers KV, un store distribuit global, pentru metadata de rutare critică, astfel încât ratările de cache să ajungă rar la bazele de date centrale.
• Accesează Postgres central prin Hyperdrive pentru pooling eficient, rutare optimizată și caching, cu replici de citire acolo unde se poate.
• Precalculează periodic agregările în baza de date, ca să eviți interogări de scanare în timpul cererilor utilizatorilor.
• Folosește consistență eventuală și cozi între componente care nu au nevoie de consistență puternică.
• Testează la încărcare cu volume-realiste ca să descoperi gâturile de sticlă și să le optimizezi pe cele dintâi.

Aceste principii nu sunt teorie de conferință. Sunt reguli pe care le aplici atunci când construiești ceva ce trebuie să reziste la milioane de instanțe și la trafic imprevizibil.

Separarea care face diferența: plan de date versus plan de control

Ideea centrală a arhitecturii D1 este separarea clară a operațiunilor în trei categorii:

Planul de date = orice interogare de bază de date. Trebuie să fie cât mai rapid posibil și mereu la edge.

Planul de control = operațiuni HTTP API și fluxuri interne care rulează ca răspuns la cereri care nu sunt interogări. Pot depinde de componente centralizate într-o singură regiune.

Planul asincron de fundal = fluxuri analitice și de facturare, care pot fi eventual consistente și pot rula oriunde.

Această separare rezolvă o tensiune fundamentală. Interogările trebuie să rămână rapide, chiar dacă în spate există o bază de date centrală care ține evidenta. Operațiunile de creare, ștergere, listare, import/export nu au aceleași cerințe de latență, așa că pot accepta un drum mai lung.

Într-o lume în care tot mai multe aplicații sunt generate cu asistență AI, modelul acesta devine norma, nu excepția. Un vibe coding platform creează automat baze de date pentru fiecare proiect al fiecărui utilizator. Fără o arhitectură care separă planurile, sistemul se blochează în propriile conexiuni.

Subiectul se leagă direct de discuțiile despre cum instrumentele AI schimbă felul în care construim produse, temă atinsă și în analiza despre Gemini 4 Argon și raționamentul fizic pentru roboți, unde infrastructura și capabilitățile tehnice merg mână în mână.

Cum arată crearea unei baze de date, pas cu pas

Fluxul de creare e instructiv pentru oricine construiește un plan de control. Iată ce se întâmplă când un utilizator rulează o comandă de creare:

1. Se verifică dacă contul mai poate crea baze de date, raportat la limita de tier gratuit sau la limitele contului.
2. Se generează un UUID unic pentru bază, un ID unic de Durable Object și se inițializează obiectul cu informațiile contului.
3. Se persistă informația în Postgres, un rând per bază de date, inclusiv maparea la ID-ul Durable Object.
4. Se scrie maparea de la ID-ul bazei la ID-ul Durable Object în Workers KV, folosită apoi de planul de date.

Punctul important: verificarea numărului de baze de date se face pe replici de citire Postgres prin Hyperdrive, cu caching activat și TTL de câteva secunde. Iar endpoinții care fac mai multe drumuri dus-întors către Postgres sunt rutați către centre de date apropiate de clusterul Postgres, pentru că un round-trip de la distanță poate costa sute de milisecunde, în timp ce aproape de Postgres costă câteva milisecunde.

Există un detaliu subtil, dar crucial: la crearea implicită, Cloudflare vrea ca baza de date să fie aproape de utilizator. Așa că, în timpul creării, requestul e redirecționat intern către un centru de date apropiat de locația cererii originale, iar Durable Object-ul e invocat de acolo. Rezultatul: obiectul e poziționat lângă utilizator, chiar dacă operațiunea de control s-a executat lângă Postgres.

Se poate influența locația bazei de date printr-un location hint explicit sau printr-o jurisdicție, opțiuni identice cu cele pe care le suportă Durable Objects.

Autocorecția și idempotența: inima fiabilității

Partea cea mai interesantă din material este modul în care sistemul se repară singur. Pașii de creare sunt împachetați într-o buclă de retry. Când inițializarea Durable Object sau scrierea în Postgres eșuează, se reîncearcă cu ID-uri diferite.

De ce ID-uri diferite? Pentru că, dacă ai refolosi UUID-ul bazei de date cu ID-uri noi de Durable Object, mai multe obiecte ar crede că dețin aceeași bază de date, ceea ce duce la situații greu de depanat. Cu ID-uri noi la fiecare retry, doar unul rămâne valid.

Scenariul de eșec, așa cum îl descrie Cloudflare: se execută tot până la inițializarea Durable Object A, apoi scrierea în Postgres eșuează. Worker-ul reîncearcă bucla și inițializează un obiect nou, cu ID diferit B, iar de data asta persistă în Postgres. Acum există două Durable Objects pornite, dar doar unul e valid. Utilizatorul poate interoga doar obiectul B, pentru că doar acel ID există în Postgres, sursa de adevăr. În maximum 30 de secunde, obiectul A trimite următorul heartbeat către planul de control și primește răspunsul că baza lui nu există. Se marchează singur ca șters.

Heartbeat-urile rulează la fiecare 30 de secunde, cu un jitter per bază de date, și pot fi modulate sau dezactivate. Toleră date ușor învechite, așa că pot fi servite din straturile de caching ale Hyperdrive sau dintr-o replică de citire Postgres.

Un alt detaliu de ordonare: Durable Object-ul trebuie inițializat înainte de a persista maparea în Postgres. Altfel, cererile de interogare ar putea ajunge la un obiect neinițializat și ar fi respinse.

Există și o întrebare firească: de ce nu rulează tot fluxul de creare într-o singură tranzacție Postgres? Răspunsul e simplu și tranșant. Nu scalează, pentru că ar însemna să ții conexiuni deschise cât timp se inițializează un Durable Object care poate fi la capătul opus al lumii.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă nu scrii cod de infrastructură, s-ar putea să crezi că subiectul nu te privește. Greșit.

Primul impact e indirect, dar real: platformele pe care le folosești pentru a-ți construi produse digitale devin mai ieftine și mai rapide la scalare. Când un furnizor de infrastructură serverless rezolvă problema creării de milioane de instanțe, costul marginal al unei aplicații noi scade. Asta înseamnă că experimentele tale în e-commerce sau SaaS devin mai accesibile.

Al doilea impact ține de ce ceri de la furnizori. Când evaluezi o platformă, întreabă explicit: datele mele stau la edge sau trec prin gâturi de sticlă centralizate? Cum se comportă la creștere bruscă? Ce se întâmplă când un proces eșuează la jumătatea drumului? Întrebările astea separă infrastructura serioasă de cea care arată bine în demo.

Al treilea impact privește decizia de a construi intern. Dacă ai un produs multi-tenant în care fiecare client are propriul spațiu de date, modelul descris de Cloudflare e un argument pentru arhitectura per-tenant în locul unui cluster unic partajat.

Aici se leagă și de discuția despre cum se schimbă indicatorii de performanță atunci când datele devin mai granulare, temă atinsă în analiza despre Salesforce și achiziția Loops, unde granularitatea și explicabilitatea metricilor schimbă deciziile de business. La fel, în ghidul despre alegerea platformei de email marketing, criteriul infrastructurii contează mai mult decât lista de funcții pe hârtie.

Pentru un marketer, traducerea practică e simplă: infrastructura pe care rulează datele tale influențează viteza, costul și fiabilitatea. Nu e o detaliu tehnic de ignorat când calculezi marja.

Ce rămâne de verificat înainte să te bazezi pe asta

Materialul Cloudflare descrie arhitectura internă, ceea ce înseamnă că nu poți valida toate detaliile din exterior. Iată ce aș verifica înainte să iau decizii:

• Ce garanții de latență există pentru interogările din planul de date în regiunile unde am utilizatori.
• Cum se comportă heartbeats-urile și autocorecția la scară de zeci de mii de baze de date pentru un singur cont.
• Ce se întâmplă la migrarea unei baze dintr-o regiune în alta și cât durează.
• Cum se reflectă separarea planurilor în facturare, pentru că operațiunile de control pot avea costuri diferite.
• Ce limite concrete există la crearea în masă și cum se comportă la depășirea lor.

O verificare incompletă nu dovedește absența unei funcții. Nu trage concluzii dintr-un test parțial. Testează cu volume-realiste și măsoară.

Întrebări frecvente

Ce este D1 și cu ce diferă de o bază de date tradițională? D1 e baza de date serverless administrată de Cloudflare, construită pe SQLite. Diferența majoră e modelul: în loc de un cluster mare per aplicație, permiti milioane de baze mici, fiecare susținută de un Durable Object, și plătești doar ce folosești.

De ce nu poate crearea unei baze de date să ruleze într-o singură tranzacție Postgres? Pentru că nu scalează. Ar însemna să ții conexiuni deschise cât timp se inițializează un Durable Object care poate fi la mii de kilometri distanță. În loc de asta, Cloudflare folosește o buclă de retry cu ID-uri noi și heartbeats care curăță obiectele orfane în 30 de secunde.

Ce înseamnă separarea între planul de date și planul de control? Planul de date e tot ce ține de interogări și trebuie să rămână rapid, la edge, fără componente centralizate. Planul de control e tot ce ține de creare, ștergere, listare, import/export și poate accepta latență dinspre un centru de date central. Separarea permite fiecăruia să fie optimizat pentru cerințe diferite.

Concluzia ALLSoft Agency

Arhitectura descrisă de Cloudflare arată clar unde se termină automatizarea și unde începe judecata umană. AI-ul ajută la analiză și planning, la generarea de scenarii și la testarea de ipoteze, dar deciziile de arhitectură, alegerile de compromis și execuția rămân umane. Un media buyer senior nu cumpără o arhitectură pe încredere, o validează pe date.

Iar pasul concret îl face ALLSoft Agency: măsurăm, testăm și traducem infrastructura tehnică în decizii care contează pentru bugetul tău. Fără hype, fără promisiuni pe hârtie.