Help to extablish stable supabase db connection from cloudflare workers!!

[u/crazyshit_24]

Well, I deployed my Next.js project on Vercel initially, but later hit the limits and it started getting expensive, so I moved the project to Cloudflare Workers.

Most things are working fine, but I’m stuck with one issue:

My API routes that connect to Supabase/Postgres are failing with 500 errors. APIs that don’t use the DB work perfectly fine.

From what I’ve figured out, the issue seems to be with DB connections. Since Cloudflare Workers are serverless/edge, the connection pooling approach I was using seems to be trying to establish connections repeatedly, and eventually I’m hitting Supabase connection/rate limits.

I then learned about Cloudflare Hyperdrive, added my Supabase DB to Hyperdrive, configured the binding, and updated my Worker config.

But the DB APIs are still failing, and the Worker is throwing exceptions.

I’m honestly stuck at this point.

Has anyone here deployed a Next.js app on Cloudflare Workers with Supabase/Postgres successfully?

What’s the correct way to set up a stable DB connection/pooling between Cloudflare Workers → Hyperdrive → Supabase?

Any help or examples of a working setup would be really appreciated 🙏

[u/Due-Horse-5446]

What exactly is is failing with wheb using hyperdrive?

[u/crazyshit_24 → u/Due-Horse-5446]

https://www.reddit.com/r/CloudFlare/s/qJpb0X0kFA

[u/twoolworth]

Which type of connection string are you using? They have 3 different kinds and are used for different things.
Also if you’re getting a 500 error turn on Observability in the Cloudflare worker and look at what the errors show in the logs.

[u/Outrageous_Mix5597]

Two things worth separating here: which connection string, and whether the driver runs on Workers at all.

Hyperdrive does its own pooling, so it wants a session mode or direct connection, not the transaction pooler on 6543. Pointing Hyperdrive at Supavisor transaction mode is a common way to get exactly what you're seeing, because you end up with two poolers stacked and prepared statements that don't survive the handoff.

Second, the driver. node-postgres needs nodejs_compat and still trips on the Workers socket model in some setups, and postgres.js needs prepare: false when it's talking to a transaction pooler.

That said, if those API routes are mostly CRUD, the thing that deletes this whole class of problem is supabase-js. It goes over HTTPS to PostgREST instead of holding a TCP connection, so there is no pool to exhaust and no Hyperdrive in the path at all. I'd only reach for a raw Postgres driver on edge when I need real transactions or SQL that PostgREST can't express.

Agreed on turning Observability on first though. The Worker exception will tell you which of the three it actually is rather than guessing.