I would say that defeats much of the point of deploying your app to workers

well, people who have ever run postgres in production would think that

and people who haven't would quickly learn 🙂

but again, if you want to keep it easy then you can get the benefits of Postgres by using a service like Supabase (this is what we do)

The thing you're missing above is that a DO-based pool would unlock more features and better perf for workers connecting to pg

yeah... I get that. but it doesn't exist yet lol. so I am talking about real world practical things here and you are talking about theoretical things that might exist in the future and won't be production ready for several months

Lots of untapped potential here once socket support ships IMO

I would rather use a battle tested connection pooler that handles edge cases than a DO library used by 5 people

even popular DO libraries like

itty-durable

have their issues in production

so I am little cynical after running into these issues

lets just say I wouldn't eagerly use a brand new DO Postgres connection pooler in prod when there are many other options 😉

The other option is to just pay a serverless pg SaaS to do it for you I guess

yeah that is what I suggested: > but again, if you want to keep it easy then you can get the benefits of Postgres by using a service like Supabase (this is what we do)

you get other nice things with it like webhooks and a whole auth system

not just postgres

That's still using http right? Assume there's some perf impact there or nah?

yeah it is over HTTP. we barely call Supabase from our Workers, we try to keep them separate as much as possible (most requests made from the client/browser). so haven't tested it. but Supabase keeps a connection pool on their end so you would just be getting hit with creating the HTTP connection but I'm sure we could cache that between requests pretty easily in Workers

Supabase uses PostgREST which has its own connection pooler from my understanding

it would be the same performance I think as calling something like pgbouncer directly

I don't think that in practice the difference between TCP and HTTP would really be measurable for this sort of use case. the bottleneck is always going to be Postgres by far

Is there some latency issue with deploying Workers right now?

I'm running

wrangler publish -e staging && wrangler tail -e staging

, but it doesn't seem like my Worker is actually being updated.

i actually came here cause i noticed the same thing, my worker failed to publish because of

Error [ERR_SOCKET_CONNECTION_TIMEOUT]: Socket connection timeout

. Try running

wrangler publish

a few times as that ended up actually fixing it for me.

I'm just starting to look into this, but I want to create a serverless web function that takes a MP4 url (currently stored on R2), and a start time/end time, uses ffmpeg to slice it and then upload the result back to R2. Would this be something I could use Workers for?

You can't use ffmpeg on workers so it wouldn't work

ah :/

even compiled versions? like https://www.npmjs.com/package/@ffmpeg/ffmpeg

Yeah that packaged version has stuff that isn't compatible with workers runtime because of dependencies.

I feel like if it's a compiled web assembly package it should be self-contained, right?

ts
  "dependencies": {
    "is-url": "^1.2.4",
    "node-fetch": "^2.6.1",
    "regenerator-runtime": "^0.13.7",
    "resolve-url": "^0.2.1"
  },

looking at the github package.json it has these dependencies, but I''m not sure if all of them are needed to interact with the wasm