Hyperdrive (PlanetScale Postgres) support

[SamJB123]

Clear and concise description of the problem

CloudFlare's seemed to double down on Planetscale Postgres, linked via Hyperdrive, as the best option with most first-party integration for anyone whose database needs aren't met by D1. If Lunora supported reactive updates/hooks from such DBs, this would become a powerful CloudFlare-native pathway to making a postgres database reactive.

Affected package(s)

New package

Suggested solution

I'm guessing this would take some exploration on the best pathway. Hyperdrive might not be the only way. For example, linking a postgres database's write-ahead log up to CloudFlare Queues is another (IIRC, the write-ahead log is how convex itself powers reactive updates under the hood as well).

Alternative

No response

Additional context

No response

[prisis]

Good news — this landed. @lunora/hyperdrive ships two surfaces, and the second one is exactly what you're describing.

1. ctx.sql — action-only, non-reactive

The escape hatch for a database Lunora doesn't own. Available on ActionCtx only (the hyperdrive_outside_action advisor lint enforces it), and writes through it produce no change events. Right tool for "read/write my legacy Postgres from an action," wrong tool for "make my Postgres reactive."

2. .global({ backend: "hyperdrive" }) — first-class and reactive

PlanetScale Postgres/MySQL over Hyperdrive as a .global() storage backend, alongside D1:

// lunora/schema.ts
export default defineSchema({
    orders: defineTable({ ... }).global({ backend: "hyperdrive" }),
});

Codegen picks that up and emits a .hyperdriveGlobal() declaration on the app builder; you supply the writer inside the DO that hosts the store (the HYPERDRIVE binding is reachable there):

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 });

createMysqlGlobalCtxDb is the MySQL twin — it must be constructed with flags: ["FOUND_ROWS"], or the affected-rows OCC guard sees changed instead of matched rows and an idempotent patch raises a false conflict.

How the reactivity works. Lunora owns the schema here — a .global() table gets a real column-per-field layout, and every write routes through the shared store core (@lunora/sql-store) with a Postgres/MySQL dialect and a Hyperdrive-backed exec. The resulting writer is injected as globalDb into createShardCtxDb, whose broadcast hook is the same one that drives live queries over D1. So subscriptions stay reactive with zero extra wiring — no WAL tailing, no replication slot, no Queues hop.

Already on a D1 .global() dataset? lunora migrate d1-to-hyperdrive --from-url … --to-url … copies it over (--tables to scope it, --out to keep the intermediate NDJSON dump).

Docs: https://lunora.sh/docs/packages/hyperdrive (shipped in @lunora/hyperdrive@1.0.0-alpha.48).

On the write-ahead-log idea

Worth being precise about the boundary, because it's the one thing the above doesn't give you: reactivity comes from owning the write path. Writes issued through Lunora broadcast; writes another system makes directly against PlanetScale do not — Lunora never sees them.

Ingesting the WAL is a deliberate non-goal. Logical replication would mean owning replication-slot lifecycle, slot-lag backpressure, and schema-change handling, and it buys exact invalidation we already get for free by sitting on the write path. If you need reactivity over a database Lunora doesn't own, the supported pattern is a projection into a Lunora table — pullSourceRows / projectSourceRow are the read side of that bridge, driven from a cron or a queue consumer.

So: if Lunora is the writer, .global({ backend: "hyperdrive" }) gives you a reactive Postgres today. If something else is the writer, project it in.

Happy to keep this open if the external-writer case is what you're actually after — that's a genuinely different feature and worth tracking separately.

[SamJB123]

This is fantastic!

Owning the write path seems like a very fair decision.