Supabase Just Raised $500M at $10.5B and Said Agents Deploy Most of Its Databases. Your Backend Vendor Is Now a Decacorn Optimizing for the Agent, Not You.
On June 4, Supabase closed a $500 million Series F at a $10.5 billion post-money valuation, led by GIC. The detail that matters more than the dollar figure: Supabase said agents now deploy the majority of new databases on the platform, and named Claude Code its single largest source of new projects. If you're a solo operator who hand-built an app on Supabase, you just became a minority user of your own backend.
That's not a complaint about the company. Supabase shipping fast is good for you. But when a vendor's growth engine flips from "developers building products" to "agents spinning up databases," the gravity of the whole platform shifts, and it's worth being clear-eyed about which way.
The numbers, and what they actually say
The round was $500M at $10.5B, led by GIC, with Accel, Y Combinator, Coatue, Stripe, and Salesforce Ventures in the mix. Supabase roughly doubled its valuation in about eight months and reported something like a 600% year-over-year increase in databases. Alongside the raise it previewed Multigres, an open-source horizontal scaling layer for Postgres that adds sharding, zero-downtime migrations, and high availability.
The framing in the announcement is the tell. Supabase described the raise as accelerating its lead in "agentic infrastructure." The growth story is vibe-coding tools and AI agents generating projects at a rate no human developer cohort could match. Claude Code being the top contributor of new projects isn't a fun fact. It's the strategy. The company doubling its valuation every few months is doing it on the back of machines creating databases, not people.
What shifts for you when the agent is the customer
Product priority follows revenue and usage. When the fastest-growing, most-watched cohort is agents and the vibe-coding crowd, the roadmap optimizes for that workflow: instant provisioning, throwaway projects, the path of least resistance for a tool generating a backend in one shot. None of that hurts you directly. But the features you'd want as someone running a real product for real users (predictable pricing at scale, fine-grained controls, the unglamorous reliability and migration tooling) compete for attention against making agent-driven creation even smoother.
The second shift is depth of lock-in. Supabase has spent years expanding from "hosted Postgres" into auth, storage, edge functions, vector search, queues, and realtime. Every piece you adopt is convenience while you're building, and a tendon you have to cut if you ever leave. A decacorn with a war chest will keep extending that surface, because the more of your stack lives inside the platform, the more durable their revenue. That's rational for them. It's a cost for you, and it compounds quietly.
The third is repricing risk. A company valued at $10.5B has investors who expect that number to be justified by margin eventually. I'm not predicting a price hike. I have no evidence of one. I'm saying the structural pressure points one direction, and "the generous free tier and cheap Pro plan stay exactly as they are forever" is not a bet I'd build a business on without a fallback.
Keep your exit cheap
Here's the genuinely good news, and the reason I'm not telling anyone to flee. Supabase's core is open source, and underneath all of it is Postgres. That is a real, exercisable escape hatch, not a marketing line. If you keep your discipline, leaving stays cheap.
What that discipline looks like in practice: keep your schema and data in standard Postgres with no hard dependency on a proprietary extension you can't replicate. Treat the convenient platform features as accelerants, not foundations: if your entire auth flow assumes Supabase Auth's exact behavior, you've welded a panel on; if you can swap it for another provider in a weekend, you haven't. Take a portable backup on a schedule and actually test restoring it somewhere else once, so "I can leave" is a thing you've done, not a thing you assume. The Multigres scaling story is a reason to stay, not a reason to forget the door exists.
I run this way on every managed dependency I have, and it costs me maybe an afternoon of setup per service. The afternoon is the insurance premium. The thing it insures against is waking up to a pricing email or a deprecation notice with no move available.
The honest take
It's possible I'm overweighting the agent framing. A backend that's flush with cash, shipping a credible Postgres scaling layer, and growing 600% is a backend that's going to be around and getting better, and "Claude Code deploys a lot of databases here" might just mean the tool is good and lots of people, including hand-builders, reach for it. The open-source core genuinely de-risks the relationship in a way most SaaS dependencies don't. If you're early, on the free tier, and shipping, this is not a moment to rearchitect.
But run the one-afternoon exit drill anyway. Build on Supabase because Postgres is the right call and the platform is excellent. Just don't build on it because you've quietly assumed you'll never leave. That assumption is exactly the thing a decacorn is engineered to make true. The cheapest time to keep your exit open is before you need it.
Author
Lukas
@lukcombinator