Supabase is the Postgres development platform, built by developers for developers. We provide a complete backend solution including Database, Auth, Storage, Edge Functions, Realtime, and Vector Search. All services are deeply integrated and designed for growth.
Supabase is the open-source Postgres development platform that 10M+ developers and thousands of enterprises depend on every day. We're hiring a Branching PM to own the whole path a change takes from a laptop to production: local development with the CLI, migrations and seed data, configuration as code, an isolated branch per pull request, the GitHub integration that tests it, and the promotion to production. Agents now drive a growing share of this workflow: they open branches in parallel, run migrations constantly, and need feedback in seconds. The path has to hold for people and agents alike.
What You'll Be Responsible ForTalking to customers across the full spectrum. Indie developers running the CLI for the first time, startups wiring up a branch per pull request, platforms that provision environments on Supabase for millions of their own end users, and enterprise teams who need a documented route from development to staging to production. They ask for features. You find the need behind the ask, and those needs set the roadmap.
Making the pieces feel like one workflow. The CLI, migrations, seeds, configuration, branches, and Git integration have to land on developers as one path. You decide where one tool ends and the next begins, and the mental model is yours to defend.
Owning the outcome of each launch, and defining how it's measured before it ships. The metric, the threshold, and the read afterwards are yours: time to a developer's first migration, branch adoption, the share of teams shipping through a reviewed workflow. Shipping starts the measurement, and the read decides the next call.
Owning the problem statement and the commercial shape behind every bet. You capture the customer evidence, name the constraints (provisioning latency, compute capacity, cost per environment, how much production data an environment can hold), and set each target at how good it needs to be. Every environment costs compute, so you decide what stays free to win a developer and what a company pays for.
Deciding what gets built, what gets deferred, and what gets cut. Every quarter you're choosing between local development ergonomics, partner platforms that run their whole user base on this workflow, enterprise release requirements, and the infrastructure work that all of it runs on. You know the path's SLOs and what spending the error budget costs the roadmap. The priorities are yours to defend, and the written non-scope settles most mid-flight asks.
Keeping engineering, design, and leadership aligned. Your roadmap runs through compute, storage, the CLI, the dashboard, and the GitHub integration. You write it down, surface dependencies before they become blockers, and keep decisions moving.
Have 7+ years of product management experience on developer tools, or you're an ex-founder with strong product instincts. Technical here means hands-on: you follow a design discussion, get into the code when the answer lives there, with or without AI assistance, and form your requirements from what the system actually does.
You've shipped developer-workflow products. You've owned at least one of local development tooling, migrations, CI/CD, ephemeral or preview environments, or Git-integrated deploys. You understand the tradeoffs well enough to judge them: what belongs in a CLI vs. a dashboard, schema-only environments vs. environments with data, copy-on-write clones vs. dump-and-restore, why branching is cheap and merging stateful systems isn't, and how much of a workflow can live in a config file before developers stop reading it. Familiarity with the Postgres ecosystem (migrations, extensions, tooling) is a bonus.
You're biased toward action. You break big bets into pieces that ship early, treat each release as a test of your assumptions, and deliver carefully enough that this quarter's launch doesn't become next quarter's support burden. You measure speed by how fast the outcome arrives.
You build with what you own. You run the workflow yourself: a project running locally, migrations and seeds under version control, a branch opened off a pull request, and a promotion to production you'd trust on a Friday.
You use AI to move faster. You reach for AI tools to cut the slow parts and spend the time you save on judgment calls.
You work async by default. You make decisions in writing and move threads forward without meetings.
Fully Remote
We hire globally. We believe you can do your best work from anywhere. There are no Supabase offices, but we provide a WeWork membership or co-working allowance you can use anywhere in the world.
ESOP
Every team member receives ESOP (equity ownership) in the company. We want everyone to share in the upside of what we’re building together.
Tech Allowance
Use this budget to set up your ideal work environment—laptop, monitor, headphones, or whatever helps you do your best work.
Health Benefits
Supabase covers 100% of health insurance for employees and 80% for dependents, wherever you are. Your wellbeing and your family’s health are important to us.
Annual Off-Sites
Once a year, the entire company gathers in a new city for a week of connection, collaboration, and fun. It’s a highlight of our year.
Flexible Work
We operate asynchronously and trust you to manage your own time. You know what needs to be done and when.
Professional Development
Every team member receives an annual education allowance to spend on learning—courses, books, conferences, or anything that supports your growth.
Supabase was born-remote and open-source-first. We believe our globally distributed team is our secret weapon in building tools developers love.
~400 team members
60+ countries
20+ languages spoken
Over $1B raised (including our $500M Series F)
540,000+ community members
We move fast, build in public, and use what we ship. If it’s in your project, we probably use it in ours too. We believe deeply in the open-source ecosystem and strive to support—not replace—existing tools and communities.
