Every verified stack that runs on Edge (Cloudflare Workers).
Edge/Workers runtime: Neon's HTTP driver (no TCP sockets exist on Workers).
0 verified stacks
No verified stacks published yet.
What Edge (Cloudflare Workers) gives you
Cloudflare Workers have no TCP sockets, and that single constraint decides everything this target emits. `postgres`/`postgres-js` and `mysql2` both open raw TCP connections, so neither can run on this runtime at all — ship one anyway and the app type-checks, builds, deploys, and then throws on its first query in production, which is the worst possible place to learn it. The Postgres branch therefore emits Neon's HTTP driver, `neon(process.env.DATABASE_URL!)` from `@neondatabase/serverless`, bound through `drizzle-orm/neon-http`. Every query becomes an HTTPS request to Neon's SQL endpoint, which is transport the Workers runtime genuinely provides. The MySQL branch reaches the same conclusion by the same reasoning: `new Client({ url: process.env.DATABASE_URL! })` from `@planetscale/database`, bound through `drizzle-orm/planetscale-serverless`.
Because a query is a request rather than a session, there is no client-side pool here and nothing to size — no `max`, no `connectionLimit`, no idle timeout. That is the real distinction from the other two targets, both of which spend their entire configuration budget deciding how many backends one process may hold. Here nothing is carried between invocations, so a Worker evicted between two requests loses nothing worth keeping, and the concurrency ceiling belongs to the database's HTTP endpoint rather than to a number in this file. The trade is paid per query: a fresh HTTPS round trip with no connection reuse, and no home for anything that assumes a connection held open across statements.
On the Postgres branch the exported `sql` is still a tagged template, so raw SQL in an edge app reads exactly as it does on the socket-based targets even though it travels over fetch, and `db` is the same Drizzle handle every other emitted artifact imports.
Built for
`neon(process.env.DATABASE_URL!)` from `@neondatabase/serverless` speaks Postgres over fetch, and `drizzle-orm/neon-http` binds it — the wiring that works on a runtime with no TCP stack.
The Postgres branch never imports `postgres`; the choice is made at compose time so an edge cell cannot ship the driver that would deploy cleanly and then fail on its first live query.
The MySQL branch uses PlanetScale's HTTP client (`new Client({ url })` plus `drizzle-orm/planetscale-serverless`), the MySQL counterpart to Neon's driver, rather than trying to make `mysql2` work where it cannot.
No `max`, `connectionLimit`, or idle timeout appears in the emitted client, because each query is an independent HTTPS request. There is no per-instance connection budget to get wrong and nothing leaked between invocations.
The Postgres branch still does `export const sql`, and `neon()` returns a tagged template, so a query written against the serverless or Node target ports to edge unchanged even though the transport underneath is fetch rather than a socket.
Why Edge (Cloudflare Workers), specifically
Cloudflare Workers have NO TCP — postgres-js fails at runtime there; the @neondatabase/serverless HTTP driver is required.
Each query is a stateless HTTPS request, so there's no client-side pool to size.
What Edge (Cloudflare Workers) pulls in
bun add @neondatabase/serverless drizzle-ormDATABASE_URLNeon connection string (HTTP driver)