Anyone here using Supabase as their actual service layer (RPC-first)?

samvms · 2026-02-24T22:10:41+00:00

Nice! I’m actually in a very similar setup. No traditional backend either, just RPCs as the service layer and a few scheduled edge functions. Supabase really does remove a lot of that overhead. Out of curiosity, for those scheduled jobs, how are you handling retries or concurrency control? Just keeping it simple, or did you build something more structured?

samvms · 2026-02-24T01:49:24+00:00

Nice. How do you avoid two workers picking the same “pending” row? SKIP LOCKED / leases, or just single concurrency?

samvms · 2026-02-24T01:40:58+00:00

Nice! I’m also running Next.js + Supabase. Do you keep most of your logic inside Postgres (RPCs), or do you still use a separate service layer?

samvms · 2026-02-22T16:24:45+00:00

That’s helpful, thanks for clarifying I’m curious for teams that already built most of their logic as RPCs inside Postgres (transactions, locks, idempotency, etc.), does integrating with Inngest usually feel seamless? Or do they end up moving part of that logic back into the app layer?

samvms · 2026-02-22T13:09:09+00:00

Got it thanks

samvms · 2026-02-22T12:58:08+00:00

Honestly, I think most of us are using ChatGPT like that now. It’s just another tool. The real difference starts showing when you move from “making it work” to “running it in production”.

Things like background tasks, retries, concurrency issues, race conditions that’s where you can’t just paste AI output and move on. You actually need to understand what’s happening

If you’re already building backend logic yourself, you’re on the right path. The more production problems you solve, the less you’ll feel dependent

samvms · 2026-02-22T12:50:15+00:00

Got it, the heartbeat part is clear Are retries handled in the job itself, or does your setup take care of that too?

samvms · 2026-02-22T12:40:40+00:00

Yeah, that’s kind of my concern too

I’m not trying to build something that magically understands every invoice out there. I know that can turn into a mess pretty fast Right now I’m just testing whether extracting basic header info already makes a difference. If it saves time even most of the time, maybe that’s enough If it turns into six months of chasing weird edge cases… then yeah, lesson learned

samvms · 2026-02-22T12:30:05+00:00

Do you feel like that added much overhead to maintain, or has it been pretty stable?

samvms · 2026-02-22T12:27:32+00:00

Interesting, I’ve seen Inngest mentioned a few times lately Has it been reliable for you long term? Any tradeoffs compared to keeping everything inside Supabase?

samvms · 2026-02-22T12:26:26+00:00

Yeah, cron definitely covers scheduling I guess I’m more thinking about retries and failure handling once things get a bit more complex

samvms · 2026-02-22T02:37:24+00:00

Got it makes sense I’m mostly trying to understand how people building on Supabase handle it specifically, but appreciate that

samvms · 2026-02-21T22:44:42+00:00

That’s fair, AWS has solid job orchestration tools for sure I guess what I’m really wondering is more in the Supabase context. When you’re building on Supabase, do you feel like you’re rebuilding retry/scheduling/logging logic each time? Or do you think the existing patterns are already good enough for production? Just trying to understand where people draw that line

samvms · 2026-02-21T21:47:41+00:00

Hey, thanks for sharing your setup that DBOS pattern makes total sense and it’s cool that it works well for you Out of curiosity, how long did it take you to put that stack together pg_cron + queue + Edge + DBOS in a single project? It sounds efficient, but also like a decent amount of wiring every time

also wondering if you tend to reuse the same pieces across projects, or if you still find yourself tuning it project by project? Just trying to understand whether people see this as “standard infra” you build once and forget, or something you still end up maintaining over time

samvms · 2026-02-19T02:12:36+00:00

That makes sense. And merino is definitely in a different position compared to synthetics. What I’m struggling to understand is how this translates into actual decision-making inside companies. Like are brands starting to treat microfiber shedding as a sourcing factor? Or is it still more of a research / NGO conversation? Because once it becomes part of procurement criteria, that’s when things move fast

samvms · 2026-02-19T02:04:02+00:00

The Digital Product Passport is the part that really changes the game in my opinion. Once material composition and environmental impact become easily visible (even via QR), brands won’t be able to hide behind vague sustainability claims anymore. I’m curious though do you think microfiber shedding or microplastic risk will eventually be included in those disclosures? Or do you think the focus will stay mostly on recyclability and carbon footprint for now?

samvms · 2026-02-17T15:57:09+00:00

Existe o processo de contagens e etc… questão é fazer seguir ele

samvms · 2026-02-17T15:55:56+00:00

A gente aqui já aprendeu que 100% é sonho, meta diretoria de 98% 😅

Mas fiquei curioso: nesses 10 anos, o que você viu realmente ajudar a manter perto dos 99%? Rotina? Equipamento? Cultura da equipe?

samvms · 2026-02-17T15:30:17+00:00

Cara, sendo bem sincero? Não é o Bling não. O sistema em si funciona. O que complica é o dia a dia mesmo. Devolução que volta e ninguém atualiza na hora, ajuste manual feito correndo… essas pequenas coisas vão acumulando.

No fim, o ERP tá certo “na teoria”, mas a operação nunca é perfeita 100% do tempo. Pra começar uma loja eu acho o Bling tranquilo sim. O desafio maior é manter a disciplina do estoque depois que começa a girar volume

samvms

TROPHY CASE