Devflare Docs
Application example Bindings

Use Hyperdrive in a real application path

Hyperdrive gives Workers a pooled, Cloudflare-managed connection path to existing PostgreSQL databases.

This example uses Hyperdrive in an application route that reads one product from PostgreSQL.

Use the same route locally with a local Postgres connection string, then deploy with the Cloudflare Hyperdrive configuration id or name.

Config focus
Stable Hyperdrive naming
Runtime shape
Query through
Best use
Product, order, account, or tenant data stored in PostgreSQL

Start by wiring the binding clearly in config

Minimal Hyperdrive config

Build the application flow around the binding

Treat this as the app-level Hyperdrive path: the route, event handler, or service module receives a real request and uses the binding to do useful work.

Keep product limits, remote ownership, and fallback behavior visible in the code around the binding instead of hiding everything behind a vague utility too early.

  • Install the client with and point at a local or CI Postgres database.

Read one product through Hyperdrive

Keep production boundaries visible

  • Config focus: Stable Hyperdrive naming.
  • Runtime shape: Query through .
  • Best use: Product, order, account, or tenant data stored in PostgreSQL.

Use a real local database

Hyperdrive local support means Devflare can pass the connection path through the binding. It does not create or seed PostgreSQL for you.

Previous

Testing Hyperdrive

Hyperdrive testing should start with a local connection string, then add a focused query test against the database shape your app actually uses.

Next

Browser Rendering

Browser Rendering shines in Devflare’s bridge-backed dev story: keep one browser binding, one narrow worker route, and one smoke path that proves launch works.