Seks lagringsprodukter, ingen managed Postgres: kritikken mot Cloudflare

Seks måter å lagre data på: D1, Durable Objects med sin egen SQLite, KV, R2, Queues og Hyperdrive. Ingen av dem er en administrert Postgres. Hyperdrive er en tilkoblingspool og cache foran en database som ligger et helt annet sted, skriver utvikleren bak bloggen opensauce, som publiserer under håndtaket orliesaurus, i et innlegg 7. august. Han jobber selv i en liten KI-oppstart og beskriver seg som en delvis fornøyd Cloudflare-kunde.

Samme bilde på kjøresiden, ifølge innlegget: Workers, Dynamic Workers, Sandboxes på Containers og fulle Containers, hver med ulik isolasjon, oppstartstid, prising og bindinger.

«Ingen av dem er bare stedet der du kjører kode» — orliesaurus, bloggen opensauce

Innvendingen er ikke at produktene er dårlige, men at antallet vokser raskere enn noen av dem blir ferdige. Observability er eksempelet han bruker: sporing sto fortsatt merket som åpen beta i Cloudflares egen dokumentasjon i august 2026, operasjoner uten I/O rapporteres ofte som 0 ms på grunn av Spectre-tiltak i kjøretiden, og sporingskonteksten forplanter seg ikke til tjenester utenfor Cloudflare. Da lar et kall seg ikke følge ende til ende ut av plattformen.

Poenget for deg som bygger er at valget mellom Cloudflares lagrings- og kjøreprodukter ikke står mellom likeverdige alternativer. Skal du feilsøke en agent som kaller ut av Workers, bør du regne med å sette opp egen sporing i stedet for plattformens.

Hva bør du gjøre?

1. Sjekk om sporingen dekker kallene agenten din gjør ut av Workers før du planlegger feilsøkingen rundt den. Konteksten stopper i dag på plattformkanten.
2. Trenger appen en relasjonsdatabase, avgjør tidlig om Hyperdrive foran en ekstern Postgres holder, eller om både database og kjøring bør ligge hos noen som tilbyr begge deler.