Supabase
Each of these is a real decision Supabase is working through, written so you can make the call yourself — incomplete information, someone who pushes back, no answer key.
Supabase is an open-source, Postgres-based backend development platform that provides managed PostgreSQL databases with integrated authentication, storage, realtime, and serverless functions. It serves software developers and teams building web, mobile, AI, and collaborative applications, as well as companies embedding backend capabilities into their own products. Supabase builds its Supabase Compute platform on Firecracker microVMs.
Your first one is free. No card.
20 live right now.
The rest
Classify Nix failures while the PostgreSQL release queue waits
Repeated Nix packaging failures are holding PostgreSQL releases while engineers reread the same build evidence. You must decide what the system can verify itself and where an engineer must take over.
Rank Auth risk before renewal talks expose it
Enterprise Auth accounts can look quiet while unresolved implementation risk sits across tickets, usage, and GitHub Issues. You must weigh earlier outreach against evidence weak enough to send CSMs to the wrong accounts.
Guide SAML rollouts before access workarounds become the norm
The first cohort needs 12 of 15 teams to complete SAML SSO within 90 days. You must weigh a repeatable adoption path against the security decisions each customer must keep.
Settle how to fix refreshed 401s while upgrades are hard to undo
Users at affected enterprise applications are signing in successfully, then losing API access after a session refresh. You must weigh a fast customer recovery against an upgrade commitment that cannot be cheaply unwound.
Clarify role changes before admins grant manual access
Customers are granting temporary access when SAML roles do not appear in JWT claims as expected. You must weigh faster role-change guidance against preserving the authorization boundaries that RLS depends on.
Trace recovery failures without letting AI declare the cause
Recovery investigations repeatedly produce competing explanations from the same logs and failed tests. You must decide what evidence the system can assemble and what an engineer must still confirm.
Rank renewal risk while TAMs keep the final call
Renewal preparation repeatedly starts with fragmented account history, leaving technical risk to surface in customer calls. You must weigh faster account ranking against evidence that a TAM can inspect and challenge.
Flag connection, index and RLS risks in 20 projects without overclaiming
Support cases repeatedly trace failed releases to connection limits, missing indexes, and slow RLS policies found after deployment. You must weigh useful early warnings against heuristic findings developers could mistake for certainty.
Choose recovery for 46 databases before peak traffic returns
Forty-six databases restarted, but 312 acknowledged writes still have uncertain durable status. You must weigh faster service restoration against evidence strong enough to account for customer transactions.
Shorten GIN builds before this week’s maintenance release
Seventeen GIN index builds have crossed the 30-minute migration timeout. You must weigh a targeted OrioleDB correction against a temporary PostgreSQL-compatible route.
Prove one team can test a release candidate in 30 minutes
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.
Commit 23 lagging clusters to new volumes without skipping tenant checks
Twenty-three Multigres clusters exceed 90 seconds of replication lag, and four have entered recovery. You must weigh rapid cutovers against verified tenant readiness when each storage move is costly to undo.
Stabilize aarch64 images without delaying the minor release
Nine of 141 aarch64 release candidates failed after a dependency update. You must weigh a fast dependency pin against a Nix correction that keeps later releases repeatable.
Prove residency paths before regulated customers leave discovery
Several regulated prospects are pausing before proof-of-value because they lack a deployment decision. You must weigh a repeatable residency service against the risk of implying compliance guarantees.
Choose a traffic move while transaction evidence remains incomplete
Forty-one transactions show conflicting status after a PostgreSQL minor-version change. You must weigh an irreversible traffic move against the cost of accepting another unverified write.
Stabilize checkout traffic before the weekly release window
Peak-hour API latency reached 1.9 seconds as active connections hit 98% capacity. You must weigh a quick pooling change against the customer’s ability to validate it before release.
Settle which safeguards ship in one launch so grants stay auditable
Application teams are asking for automated database access, and broad credentials create a larger blast radius than the work requires. You must weigh a narrowly useful first version against the safeguards customers need to trust it.
Sequence the patch by region while extension data is only sampled
A security release must reach older projects while sampled data flags uncertain extension and cipher compatibility. You must weigh exposure duration against a rollout sequence that could be costly to reverse once regions move.
Clear the provisioning queue without widening AWS access
Database provisioning success fell to 91.4% after a scoped policy change. You must weigh a targeted policy correction against a rollback that restores service faster but delays the control.