Something new at Supabase

Settle what certainty to offer on Spark costs while apps keep running

Published Nov 6, 2026

You’re the product manager. Your team is in the room.

The setting

is an open-source backend platform built on Postgres. Its runs as a hosted service that Supabase manages, or as packaged images that customers host themselves.

Planning another batch of Spark projects puts spending certainty against uninterrupted experiments.

A firm allowance protects a developer's budget, while an estimate leaves room for workloads whose lifetime is still unknown.

Who you’d be doing this for

“My founder asked what another hundred experiments would cost. I spent the afternoon guessing how long each one would stay awake.”

Javad Tehrani · Backend developer at a small application platform · a character in this brief

Runs batches of experimental databases and explains their spending to the engineering founder.

What is at stake

Eleven of 15 developer teams estimate database spending outside the product. You have to choose what certainty the first version offers without turning a forecast into a promise or a budget into an outage.

Why it isn’t already fixed

Every obvious fix costs something else. That’s the part you’d have to decide.

  • budget certainty vs uninterrupted experiments
  • useful estimates vs honest uncertainty
  • narrow charge coverage vs a complete spending decision
  • planning flexibility vs prepaid predictability

Why Supabase

Spark projects provision in a second and scale down when idle, so project count alone does not tell developers what their experiments will cost.

Written with these in mind

Infrastructure product managersDeveloper experience product managersExperiment-driven product builders

Not your kind of problem? 27 more at Supabase, or browse every organization.

Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.

The organization context comes from public information. The situation and characters are written for the brief.

Job postings it was written from

Public descriptions of the work at Supabase. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.

  • Product Manager - Administration & Governance (opens in a new tab)
    • Define what success looks like, instrument it end to end, and let the data guide what gets built next—from time to first project and self-service adoption to production usage and expansion across the company.
    • Know your way around controlled experimentation and data analysis, and can connect easier adoption to sustained product use.
  • Product Manager - Spark (opens in a new tab)
    • Spark projects provision in a second, scale down when idle, and are cheap to enough to use liberally, guilt-free. while keeping the Supabase interface agents already know.
    • This role owns establishing Spark as the default starting point for agent-built software and how projects grow from an early experiments into production workloads on Supabase.
  • Product Manager - Strategic Partner Integrations (regular travel to Bay Area) (opens in a new tab)
    • For a platform built on Postgres with Auth, Compute, Storage and generated Data APIs at its core, the surfaces where Supabase meets Partners and their systems are some of the most important avenues that we own - this role owns these surfaces.
    • Build with what you own, using the surfaces on your roadmap the way a Partner would: standing up an auth flow, calling the Data API, deploying a database, wiring Supabase into another product.
  • Product Lead - Infrastructure (opens in a new tab)
    • You talk to customers across the full spectrum: developers running one small project, startups whose bill is mostly compute and disk, enterprise architects running a network or security review, and partners building on Supabase.
    • Our customers range from a developer on a free project to a regulated enterprise that routes traffic through PrivateLink https://supabase.com/docs/guides/platform/privatelink and puts us through a security review before it signs.

Reporting read before this brief was written

The pieces closest to the situation in this brief.

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.

Other live briefs connected to this one, and what connects them.

Similar problems at other organizations

Like this one, each of these turns on deciding on evidence that's still thin.

The same setting, from another role

Each is set around Supabase’s Supabase Postgres Database, written for a different role. They’re separate briefs, not the same scenario.