[msdrigg]

I tried to make this work for me, but I finally gave up this week and wrote a traditional backend component for part of my backend because supabase doesn't support transactions and I am NOT going to write my whole backend in postgres functions.

[kiwicopple]

supabase does support transactions through RPC calls - I think you already understood that based on your comment but want to make the distinction clear for other readers

I can completely understand if you don't to write everything in pgpsql though. Did you also try the Deno Functions?

We've been brainstorming ways to support transactions directly from the client libs in a way that won't lock up the database if there is a network failure between database operations. It seems doable, but not something we want to rush.

[crooked-v]

Well, the simple case is to start with transactions with only queries that aren't dependent on each other, which would cover a vast majority of cases by itself - client sends an array of queries as a single network call, gets either an array back of results or a failure state.

[msdrigg]

I will give deno functions a look -- I haven't really looked into them.

And for the record I am still loving supabase overall. PostgREST works for 90% of what I want to do and I can spin up a simple stateless backend to support the other 10%.

[creakingstairs]

You could hook up Prisma (or any other Orm) to Supabase and use their transaction API. Though this will still need to be in server part of NextJS (api routes or getServerSideProps), but would be faster than rolling an entire backend.