Release candidates need a developer trial path without turning temporary environments into a new operational burden.
Fast self-service gives earlier compatibility evidence; constrained isolation keeps trial workloads separate from production risk.
Who you’d be doing this for
“I’m comparing release notes to our schema by hand because there’s nowhere safe to run the candidate.”
Ramiro Ferreira · Backend Developer
Maintains schema migrations and extension dependencies for a production application database.
What is at stake
Developers lack a safe, repeatable place to run a PostgreSQL release candidate against their schema. You must weigh broad self-service against an isolated first path that one product team can trust.
Why it isn’t already fixed
Every obvious fix costs something else. That’s the part you’d have to decide.
- self-service speed vs operational boundaries
- release fidelity vs first-version scope
- developer autonomy vs environment cleanup
- early learning vs platform commitment
Why Supabase
Supabase Postgres releases span PostgreSQL versions and extensions that backend developers need to test against real application schemas.
Written with these in mind
Not your kind of problem? 19 more at Supabase, or browse every organization.
This is the setup. The work is inside.
Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.