@lunora/hyperdrive

@lunora/hyperdrive lets an action read and write an existing Postgres/MySQL database through Cloudflare Hyperdrive — pooled, cached connections from the edge. It surfaces the binding's connection string and a driver-agnostic ctx.sql client.

Install

pnpm add @lunora/hyperdrive

npm install @lunora/hyperdrive

yarn add @lunora/hyperdrive

bun add @lunora/hyperdrive

No driver is bundled — postgres, pg, and mysql2 are heavy and the choice is yours. They are declared as optional peer dependencies; install the one you use:

pnpm add postgres        # postgres.js  → fromPostgresJs
# or
pnpm add pg              # node-postgres → fromNodePg
# or
pnpm add mysql2          # mysql2        → fromMysql2

Set up the binding

1. Create a Hyperdrive config pointing at your origin database:

   wrangler hyperdrive create my-db --connection-string="postgres://user:pass@host:5432/db" # gitleaks:allow -- placeholder, not a real secret

   This prints an id.

2. Add the binding to wrangler.jsonc. Use localConnectionString so local dev (lunora dev) connects straight to your DB without the edge proxy:

   {
       "hyperdrive": [
           {
               "binding": "HYPERDRIVE",
               "id": "<the id from step 1>",
               "localConnectionString": "postgres://user:pass@localhost:5432/db", // gitleaks:allow -- placeholder, not a real secret
           },
       ],
   }

Lunora validates the binding (it errors when binding is missing and warns when id is empty — a placeholder id can't connect), but it does not auto-provision the id: that's a remote resource only wrangler hyperdrive create can mint, so importing @lunora/hyperdrive surfaces a hint rather than writing the binding for you.

The canonical recipe

Construct your driver from the connection string and wrap it with the matching adapter to get a ctx.sql. Do this only inside an action:

import { createHyperdrive, fromPostgresJs } from "@lunora/hyperdrive";
import postgres from "postgres";

import { action, v } from "@/lunora/_generated/server";

export const importLegacyOrders = action.input({ orgId: v.string() }).action(async ({ ctx, args: { orgId } }) => {
    const { connectionString } = createHyperdrive(ctx.env.HYPERDRIVE);
    ctx.sql = fromPostgresJs(postgres(connectionString));

    // Read from external Postgres ($1, $2, … placeholders).
    const orders = await ctx.sql.query<{ id: string; total: number }>("select id, total from orders where org = $1", [orgId]);

    return orders;
});

When the codegen detects ctx.sql usage it adds sql: SqlClient to ActionCtx only — never QueryCtx or MutationCtx — with a JSDoc restating the determinism/realtime caveat.

Drivers & placeholders

The package never rewrites SQL — use your driver's native positional syntax.

Making external data reactive

Lunora cannot observe external writes, so a subscription over a defineSchema table won't re-fire when Postgres changes. To make external data reactive, project it into a DO/D1 table inside the same action — that write is on the change-feed, so live queries reading the projection re-run:

import { createHyperdrive, fromPostgresJs } from "@lunora/hyperdrive";
import postgres from "postgres";

import { api } from "@/lunora/_generated/api";
import { action, v } from "@/lunora/_generated/server";

export const syncOrder = action.input({ id: v.string() }).action(async ({ ctx, args: { id } }) => {
    const { connectionString } = createHyperdrive(ctx.env.HYPERDRIVE);
    ctx.sql = fromPostgresJs(postgres(connectionString));

    const [row] = await ctx.sql.query<{ id: string; total: number }>("select id, total from orders where id = $1", [id]);

    // This write is tracked — a `query` over `orders` re-runs for subscribers.
    await ctx.runMutation(api.orders.upsert, { id: row.id, total: row.total });
});

Reactive .global() over Hyperdrive

The @lunora/hyperdrive/global subpath is the inverse trade-off: instead of an escape hatch onto a DB Lunora doesn't own, it makes a Postgres/MySQL database a first-class, reactive .global() storage backend, alongside D1. Lunora owns the schema — a .global() table gets a real column-per-field layout and every write routes through the shared store core, so live queries stay reactive with no extra wiring.

You build the writer inside the Durable Object that hosts the .global() store (the HYPERDRIVE binding is reachable there) and inject it as globalDb. Cache the driver on the DO instance and rebuild it lazily after hibernation.

import { createPostgresGlobalCtxDb } from "@lunora/hyperdrive/global";
import postgres from "postgres";

const sql = postgres(env.HYPERDRIVE.connectionString);

const globalDb = createPostgresGlobalCtxDb({ query: (text, params) => sql.unsafe(text, params) }, { schema });

import { createMysqlGlobalCtxDb } from "@lunora/hyperdrive/global";
import mysql from "mysql2/promise";

// CLIENT_FOUND_ROWS is REQUIRED — the affected-rows OCC guard must see matched
// (not changed) rows, or an idempotent patch reports 0 and raises a false conflict.
const pool = mysql.createPool({ uri: env.HYPERDRIVE.connectionString, flags: ["FOUND_ROWS"] });

const globalDb = createMysqlGlobalCtxDb(pool, { schema });

The convenience constructors cover the common path. For custom wiring, the lower-level pieces are also exported:

• buildPgExec(client) / buildMysqlExec(connection) — turn a driver into the store's SqlExec.
• postgresDialect / mysqlDialect — the engine dialects.
• createHyperdriveGlobalCtxDb({ engine, exec, ...storeOptions }) — the general factory the two convenience constructors call.

Non-goals

• No CDC / logical replication. Lunora does not ingest your Postgres write-ahead log; the projection pattern above is the supported path to reactivity.
• No ctx.sql in query/mutation. Enforced by the hyperdrive_outside_action advisor lint.
• No bundled driver / ORM. You own driver choice and lifecycle.

Public API

From @lunora/hyperdrive/global (reactive .global() backend):

See also

• Concepts: queries & mutations — why actions are the only non-deterministic context
• Concepts: advisors — the hyperdrive_outside_action lint
• Concepts: real-time — what the change-feed tracks