Cloudflare Hyperdrive: Postgres Vom Edge Aus

Cloudflare Hyperdrive existiert wegen eines konkreten, unspektakulären Problems: Ein Worker, der in 200 Städten läuft und mit einer einzigen Postgres-Datenbank in einer einzigen Stadt spricht, ist langsamer als dieselbe Abfrage von einem Server, der direkt neben dieser Datenbank steht. Nicht ein bisschen langsamer. Oft um ein Vielfaches, und zwar aus Gründen, die nichts damit zu tun haben, wie die Abfrage geschrieben ist.

Der Reflex, wenn sich eine Serverless-Anwendung träge anfühlt, ist es, den Query-Planner zu verdächtigen oder einen Index anzulegen. Bei Workers, die mit einer regionalen Datenbank sprechen, ist die Abfrage meistens völlig in Ordnung. Das Problem ist die Verbindung.

Was Hyperdrive tatsächlich behebt: die Kosten für den Aufbau einer Datenbankverbindung, die bei jeder einzelnen Anfrage anfallen. Eine Postgres-Verbindung braucht einen TCP-Handshake, eine TLS-Aushandlung und einen Authentifizierungsaustausch, bevor sich eine einzige Zeile bewegt, und jeder dieser Schritte ist ein Roundtrip von dort, wo der Worker aufgewacht ist, bis dorthin, wo die Datenbank liegt. Hyperdrive hält warme Verbindungen in der Nähe Ihrer Datenbank vor und poolt sie, sodass der Worker sich eine offene Verbindung leiht, statt eine neue aufzubauen.

Warum ein Worker mit direkter Postgres-Verbindung langsam ist

Ein klassischer Anwendungsserver öffnet beim Start einmalig einen Pool von Verbindungen und verwendet sie über die gesamte Lebensdauer des Prozesses wieder. Die Kosten des Handshakes fallen beim Hochfahren an und verteilen sich danach über Millionen von Anfragen, bis jemand den Dienst neu startet.

Workers funktionieren nicht so. Jede Ausführung ist kurzlebig und kann an jedem beliebigen Cloudflare-Standort laufen. Es gibt keinen langlebigen Prozess, der einen Pool hält, also zahlt ohne Hilfe jede Anfrage die vollen Aufbaukosten, und sie zahlt diese Kosten über die Distanz vom Edge bis zu Ihrer Origin-Datenbank.

Drei Roundtrips vor dem ersten Datenbyte sind kein Tuning-Problem. Eine Nutzerin in Sydney, die einen Worker aufruft, der mit Postgres in London spricht, zahlt diese Latenz vierfach: TCP, dann TLS, dann Authentifizierung, dann endlich die Abfrage. Die Abfrage selbst dauert vielleicht zwei Millisekunden.

Es gibt einen zweiten, leiseren Ausfallmodus. Postgres reserviert pro Verbindung einen eigenen Backend-Prozess, und das Maximum ist endlich, typischerweise ein paar Hundert. Ein Worker, der auf Tausende gleichzeitiger Ausführungen skaliert, erschöpft diesen Pool und sammelt genau während der Lastspitze, für die Sie den Edge gebaut haben, abgelehnte Verbindungen ein.

Was Hyperdrive dagegen tut

Hyperdrive sitzt zwischen Worker und Datenbank als Connection Pooler, den Cloudflare für Sie betreibt. Es hält warme Verbindungen zu Ihrem Origin offen, sodass eine Ausführung sich eine davon leiht, statt eine neue von Grund auf auszuhandeln.

Es cacht außerdem Abfrageergebnisse. Lesende Abfragen, die sich wiederholen, lassen sich ausliefern, ohne das Origin überhaupt zu berühren, was für einen erheblichen Teil des Traffics aus einer Latenzfrage eine Cache-Hit-Frage macht. Schreibvorgänge und alles Nichtdeterministische gehen direkt durch.

Die Konfiguration ist ein Connection String. Sie registrieren die Datenbank bei Cloudflare, erhalten ein Hyperdrive-Binding und richten Ihren vorhandenen Postgres-Treiber auf dieses Binding statt auf die Datenbank. Treiber, SQL und Schema bleiben unverändert. Das wiegt schwerer, als es klingt, denn es bedeutet, dass die Änderung reversibel ist und Sie sie gegen eine direkte Verbindung messen können, ohne irgendetwas umzuschreiben.

Die Zahlen, die über die Eignung entscheiden

Im August 2026 gegen die Cloudflare-Dokumentation geprüft, und vor einer Festlegung erneut zu prüfen, denn diese Werte bewegen sich.

Hyperdrive verursacht in keinem der beiden Pläne zusätzliche Kosten , und es fallen keine Egress-Gebühren an. Was als Abfrage zählt, ist weit gefasst: ein Select, ein Insert, ein Update, ein Delete oder eine Schemaänderung zählen alle mit, und gecachte Abfragen zählen genauso wie ungecachte. Das kostenlose Tageskontingent wird um Mitternacht UTC zurückgesetzt.

Die Dokumentation zu den Limits nennt ein Timeout von 15 Sekunden für den initialen Verbindungsaufbau und ein Idle-Timeout von 10 Minuten. Die Obergrenze von 60 Sekunden pro Abfrage ist diejenige, die Teams erwischt, die eine Reporting-Last migrieren: Eine analytische Abfrage, die im Cronjob zwei Minuten braucht, schlägt hier schlicht fehl.

Welche Datenbanken wirklich funktionieren

Hyperdrive unterstützt PostgreSQL 9.0 bis 17.x und MySQL 5.7 bis 8.x , selbst gehostet oder verwaltet. MariaDB ist über die MySQL-Kompatibilität abgedeckt.

Namentlich genannte Managed-Anbieter sind AWS Aurora in seinen Postgres- und MySQL-kompatiblen Varianten, Neon, Supabase, Timescale, Materialize, CockroachDB und PlanetScale. Verwaltete Instanzen auf Azure und Google Cloud funktionieren ebenfalls.

Die praktische Einschränkung ist nicht die Engine, sondern die Erreichbarkeit. Ihre Datenbank muss aus dem Netzwerk von Cloudflare heraus adressierbar sein. Eine Postgres-Instanz, die in einer privaten VPC ohne öffentlichen Endpunkt eingeschlossen ist, braucht einen Tunnel oder eine Peering-Vereinbarung, bevor Hyperdrive sie überhaupt sehen kann, und das ist ein Netzwerkprojekt statt einer Konfigurationsänderung.

Wann Cloudflare Hyperdrive die falsche Antwort ist

Wenn die Daten an den Edge gehören. Wenn Ihr Zugriffsmuster aus Key-Value-Lookups besteht, ist Workers KV schneller und einfacher. Wenn Sie eine kleine relationale Datenbank wollen, die nahe beim Worker lebt statt in einer einzelnen Region, ist D1 das dafür entworfene Produkt. Hyperdrive ist für den Fall gedacht, dass Sie bereits Postgres oder MySQL haben und dabei bleiben wollen.

Wenn die Last analytisch ist. Die Grenze von 60 Sekunden und die Abrechnung pro Abfrage passen zu transaktionalem Traffic. Lange Aggregationen gehören auf einen Job-Runner, der direkt mit der Datenbank spricht.

Wenn Sie nicht gemessen haben. Der Fehler, den wir am häufigsten sehen, ist ein Team, das Hyperdrive einer Anwendung hinzufügt, die nie verbindungsgebunden war. Wenn ein Worker langsam ist, weil er sechs sequenzielle Abfragen absetzt, wo eine genügen würde, macht das Poolen dieser sechs Verbindungen ihn marginal weniger langsam und lässt das eigentliche Problem unberührt.

Diese Messung lohnt sich, und zwar sauber und vor allem anderen. Unser Vergleich von Cloudflare Workers und AWS Lambda zeigt, wo Edge-Ausführung wirklich gewinnt, und Cloudflare D1 behandelt den Fall, in dem das Verschieben der Datenbank besser ist als das Beschleunigen des Wegs dorthin.

Die Entscheidung richtig treffen

Messen Sie eine Anfrage von Anfang bis Ende über eine direkte Verbindung, dann noch einmal über Hyperdrive, von einem Ort weit weg von Ihrer Datenbank. Ist der Unterschied klein, liegt Ihre Latenz woanders und Sie haben sich eine Abhängigkeit gespart. Ist der Unterschied groß, haben Sie echtes Geld gefunden.

Mecanik baut und prüft Edge-Architekturen über unser Team für Softwareentwicklung , einschließlich des unspektakulären Teils, in dem jemand misst, was tatsächlich langsam ist, bevor irgendetwas umgebaut wird. Wenn Ihre Serverless-Anwendung langsamer ist als der Server, den sie ersetzt hat, ist der Verbindungspfad die erste Stelle, an der Sie nachsehen sollten.

Weiterlesen: Cloudflare Workers API bauen: Serverless-Guide 2026 , Cloudflare Queues: Hintergrundjobs am Edge , LLM-Latenz reduzieren: Caching- und Edge-Strategien und Wie man 2026 eine Web-App entwickelt .

Häufig gestellte Fragen

Welches Problem löst Cloudflare Hyperdrive? Die Kosten für das Öffnen einer Datenbankverbindung bei jeder Anfrage. Ein Worker ist kurzlebig und hält keinen Verbindungspool, also zahlt ohne Hyperdrive jede Ausführung einen TCP-Handshake, eine TLS-Aushandlung und einen Authentifizierungsaustausch über die Distanz vom Edge zu Ihrer Datenbank, bevor sich Daten bewegen. Hyperdrive hält warme, gepoolte Verbindungen nahe am Origin, sodass der Worker sich stattdessen eine leiht.

Was kostet Cloudflare Hyperdrive? Nichts über Ihren Workers-Plan hinaus. Es ist sowohl im Free- als auch im Paid-Plan enthalten, ohne separate Gebühr und ohne Egress-Kosten. Der Free-Plan erlaubt 100.000 Datenbankabfragen pro Tag, zurückgesetzt um Mitternacht UTC, und der Paid-Plan ist unbegrenzt. Selects, Inserts, Updates, Deletes und Schemaänderungen zählen alle als Abfragen, und gecachte Abfragen zählen genauso wie ungecachte.

Welche Datenbanken unterstützt Hyperdrive? PostgreSQL 9.0 bis 17.x und MySQL 5.7 bis 8.x, selbst gehostet oder verwaltet, wobei MariaDB über die MySQL-Kompatibilität abgedeckt ist. Zu den genannten Anbietern gehören AWS Aurora, Neon, Supabase, Timescale, Materialize, CockroachDB und PlanetScale sowie verwaltete Instanzen auf Azure und Google Cloud. Die Datenbank muss aus dem Netzwerk von Cloudflare erreichbar sein.

Was sind die wichtigsten Limits von Hyperdrive? Zehn konfigurierte Datenbanken pro Konto im Free-Plan und 25 im Paid-Plan, rund 20 Origin-Verbindungen pro Konfiguration im Free-Plan und 100 im Paid-Plan, eine maximale Abfragedauer von 60 Sekunden, 50 MB gecachte Antwortgröße, ein Timeout von 15 Sekunden für den initialen Verbindungsaufbau und ein Idle-Timeout von 10 Minuten. Die Obergrenze von 60 Sekunden pro Abfrage ist die, die analytische Lasten blockiert.

Sollte ich Hyperdrive oder D1 verwenden? Hyperdrive, wenn Sie bereits eine Postgres- oder MySQL-Datenbank haben, die Sie behalten wollen, und das Problem die Latenz beim Erreichen dieser Datenbank ist. D1, wenn Sie eine relationale Datenbank wollen, die von vornherein im Netzwerk von Cloudflare lebt. Sie lösen unterschiedliche Probleme: Das eine beschleunigt den Weg zu einer bestehenden Datenbank, das andere beseitigt die Distanz, indem es die Daten verschiebt.