đ Iâm Ivan. I study how top 1% startups grow.
In case you missed it:
Hello there!
Hope you managed to take some time off in August. Europeâs been pretty flat, but luckily managed to catch a few waves up at Scotlandâs finest wave-pool:
Weâre coming back with a deep-dive on the growth behind Supabase, which recently raised a $500M round at a $10B valuation, 6 years after their start:
For the non-technical you can think about Supabase like this:
Apps need a place to remember things like your login, messages, orders etc. plus a pile of âinvisible plumbingâ around it. They provide all of that âout-of-the-boxâ. If youâve ever played around on Lovable chances you used Supabase.
Their growth story is especially interesting to me because its a great example of how a small startup displaces a big player in the space (Google Firebase).
What youâll learn in this edition
The 0 to 1 story (from New Zealand to the world)
How they replicated YC conditions internally (âinternal acceleratorâ)
How they used memes + community as a growth lever
What their salespeople get paid on (something different)
How the rivals âbuilt to replace themâ end up running on Supabase
Why they âobsessâ over first database created as a key growth metric
And other growth mechanics, lets dive in.
đ Quick note on editorial + methodology: this analysis focuses on the 80/20 mechanics that explain their growth (itâs not a comprehensive profile, not an endorsement or investment advice). I use AI like a fund leverages an analyst for groundwork, the direction + judgement are mine. Company-reported figures are marked as such, treat directional estimates as directional.
From Firebase alternative â backend for agents
Hereâs how the market evolved in a nutshell:
Where we come from
Over time different software waves have had their own database:
In every cycle you see the same pattern where they win developers fast first then alienates them when they start going after bigger fish. Firebase for example was great to start, harder to scale, and then lived in Googleâs own format which made leaving hard (lock-in). Database developers wanted Postgres (open source and 30 years old), but it was a pain to set up and hard to run and scale on your own.
Where we are
As weâll see later, Supabase used this pain (and market timing) as a wedge to grab the market. Today they have almost 10 million registered devs and 250K+ paying customers, with database launches up 600% year over year (as of June 2026). Apparently over half of the most recent YC batch is building on it (full circle considering they went through the batch in 2020).
Where the market is going
Apparently 60% of new databases today are already being launched by AI agents (in the millions every month). Claude Code alone became on of the biggest contributors to new databases in 2026.
Weâre already seeing how these âon-rampsâ to intelligence (your LLM of choice, now new chokepoints for how humans use the internet) and their agents shop very differently than a human. Meaning they tend to pick from a small menu of tools (the CEO talks about 3 per job). Supabase is on that menu today for this job, but the game is moving and it is moving very fast.
Handing over a database is getting commoditised but keeping them running well at scale (fasta, reliable, safe etc) is still a hard problem especially with this incoming wave. Supabase seems to be placing bets with a few things to ride the momentum like Multigres (open-source layer for running big fleets of postgres databases) and OrioleDB (faster engine for postgres).
Now unto how they grew so fast.
Act 1: A side project
2019 â end 2021 ¡ $0 â ~$1M ARR
The 0 to 1 story (from New Zealand to the world)
The founder, Paul Copplestone, grew up in a farm in New Zealand, left school at 18 + contracted his way through university. He briefly worked at a hedge fund in Australia before joining Accenture.
In 2015 a friend of his called with a startup job in Kuala Lumpur, he jumped on a plane and co-founded ServisHero as its CTO (a marketplace that connected homeowners with service providers in Southeast Asia). The company worked, but Paul wanted to start something new. He went to Singapore for the Entrepreneur First program, which he apparently didnât stay for, but stayed there and met his now co-founder.
Ant Wilson is from Liverpool, did a masters in software engineering and spent around 10 years working in venture-backed startups.
The origin of the idea is linked to Paul solving his own problem. In his previous startup he had a chat feature (which needs the ability to update instantly for everyoneâs screen when someone sends a message). Postgres (the databased he ran for it) couldnât do it, so just for that feature he integrated Firebase (googleâs database) which could. The problem is Firebase had issues under a lot of load and customers began receiving chats out of order (breaks conversaiton).
He tried to solve it with postgres but its built-in workaround didnât work on messages that where beyond a very small size. So he decided to build the missing piece himself which was a small engine that watches the database and pushes every change to your screen when it happens, for free as open source.
The early months of their 0 â 1 went like this in a nutshell:
January 2020: Ant joins Paul and together decide to âbuild the most Y Combinator-friendly team, one of those things that so obviously should exist in the worldâ
Picked the ICP: going after vc-backed startups to grow fast first (more on this in growth lever 1).
March 2020: the âplatformâ (mvp) is a form, where users submit their details and Paul launched every database by hand.
Employee #3: Steve Chavez who was a maintainer of PostgREST (open-source tool core to their stack) joins.
Firebaseâs founder passes on investing in them: a YC partner connected them to James Tamplin, heâd apparently seen 40+ backend-as-a-service pitches in a previous wave and this looked like one more (investing is hard! In this podcast he mentions âI just didn't invest and didn't join you on the journey, which I now deeply regret.", fun fact also from the UK like Ant).
Spring 2020: go accepted into YCâs summer batch.
Now unto how they grew from there:
Growth Lever 1: Launched against Firebase by name (8 â800 databases in 3 days)
âWe sort of changed the positioning to the open source Firebase alternative and thatâs we went from like 8 databases to 800 overnight.â â Paul, activenode
They applied to YC before they had a product âworth launchingâ due to the customer list, which was the batch of startups itself (makes a lot of sense, and one of the clearest value-adds Iâve seen from a YC program, they took full advantage). These 100+ startups are basically their ideal early customers and by the end of their S20 batch they had around 80 alpha users + a launch planned for Demo Day.
For a while apparently the site said "Supabase, real-time Postgres" and according to the founders "nobody cared, it didn't explain what it is, what it does, who it's for."
In May they changed it for âthe open source Firebase alternativeâ, and even though it didnât fully account for the serendipity that came their way it certainly helped:
An early user (not them) posted the site to Hacker News (see above)
The moderator converted it into their official launch live and the second most upvoted launch HN has apparently ever seen (behind Stripe)
Got them from 8 â 800 databases in 3 days
I thought this phrase from the founder summed it well:
"product-market fit often is just like a product-positioning fit." (first round pod)
Growth Lever 2: âReplicatedâ YCâs demo day intensity inside the company (every 3 months)
âWhy donât we just pretend that weâre starting the batch again, and do our best to recreate the conditions of an accelerator internally, complete with our very own Demo Day?â â Ant Wilson, âHow we launch at Supabase,â Nov 2021
The batch pressure worked for them and they took what worked best and started implementing bits and pieces of it internally (to avoid the feared post-batch cliff).
The launch threadâs most âpopularâ demand was Auth, and Michael Seibel kept asking about it to them at his weekly office hours until it apparently got pretty uncomfortable:
"Paul, for like 4 weeks you've been telling me you're going to build auth, when the [!] are you going to ship auth?" (Accel pod)
So when the batch ended they took steps to build somewhat of an internal accelerator:
An internal âDemo Dayâ every roughly 3 months: with kick-off events, inviting speakers, custom swag every cycle etc with a basically arbitrary deadline that forces everyone to ship (constraints improve creativity!).
The first one produced the Supabase Beta: with an exit criteria of 3x Firestoreâs performance, a pen test and a public uptime page.
The second one invented the âLaunch Weekâ: after someone apparently asked "why just have one launch?" (they shipped 7 features in 5 days on March 2021)
They used the cap table to amplify: just like a yc demo day, but leveraging their angels (picked for developer-advocacy), they were part of the line items / schedule for launch
Rules: they had a fixed timeline and a flexible scope, shipping early and re-launching loudly (many times over, which is an underrated tactic). They also had the engineer who built the feature be the one who wrote the marketing.
With most of the features we ship, the person who implemented the code will be the same person who writes the marketing content. This means that the content usually includes deep technical discussion. âAnt Wilson (CTO)
Apparenly the CEO sill calls each launch week âour next demo dayâ. During this time, they manage to grow databases up 47% month over month for 18 months. It took them about 1.5 years to earn their first dollar, then in 1 year they ended with c.1M ARR (founder-stated), followed by their Series A in September 2021 (30M led by Coatue, at a time where they had around 50K databases equivalent to 16x in 9 months).
Act 2: Building the âboringâ moat
2022 â late 2024 ¡ ~$1M â ~$30M ARR
Growth Lever 3: Cut database setup from 8.5 minutes to 5 seconds and removed any friction to leave (increased user freedom and trust)
âWe first had to win the day-0 experience, like the Mongos and the Firebases... And then we smuggled Postgres.â â Paul Copplestone, First Round
Migrating databases is pretty rare, and as history showed for over 20 years the only new winners like Mongo and Firebase won by owning the moment a developer starts a project (day 0).
The founder timed the AWS way of getting to a first row of data and apparently it was around 8.5 minutes, with know-how required / not that easy. Supabase does it in about 5 seconds ad they donât even advertise that number. Early on they also downplayed Postgres itself just in case the market wanted MySQL.
The second part of this leaver was to invert Firebaseâs original sin (making you feel trapped or locked-in after an easy start):
"be there when people are getting started and then make sure that they never want to leave." - Paul
In practice:
They (kind of) undersold the product (on purpose to earn extra trust): while everyone else kept calling everything âproduction-readyâ they decided to keep the beta for 4 years (with thousands already running on it) and only claimed the âreadyâ label in April 2024 (earned trust first).
Made leaving easy (understanding buyer psychology): data sits in standard Postgres so you can pack up and leave whenever (more trust).
Made big companies wait their turn: they turned down big contracts that came with additional demands (distractions) to build custom features (only built what thousand customers want).
Growth Lever 4: Gave the software for free and only charged for keeping it running
âyou donât want to charge for the development time, you want to charge for the running time.â - Paul
Everything is open source except the platform and billing code, so you can create a database for free. They charge for operating it, keeping it fast, safe and always on. Itâs also part of the reason why Amazon could struggle to âkill themâ / an important part of their moat.
The usual suspect / fear with open source is that someone (i.e. AWS) copies your product and then sells it cheaper, but in this case Amazon already rents out Postgres through 2 of its own services (RDS + Aurora), so thereâs technically nothing new to take. The hard part for them would be running five services as one including database, logins, file storage, live update and functions (the part they charge for)
Giving it aways has kept paying the back in a few ways:
Recruiting: employee #3 maintained PostgREST and the first 50 hires came from the community (by Series B the team was 20% ex-founders!)
R&D timing: in February 2023 a stranger emailed a PR adding pgvector (ai-search extension), they merged it, hired the guy and where there first when the AI wave hit.
Free product strategy: because postgres has thousands of ready-made add-ons their âlaunchesâ are often switching one on + writing the guide for it.
Growth Lever 5: Focused marketing on free databases, community and memes
âIf I could give a free database, Iâd rather give that to developers than spending on marketing.â â Paul Copplestone, YC Startup School
Digging into podcasts I found both the CEO and the head of growth confirm that they donât spend money on paid ads. The reason is that at their scale paid users tend to arrive with worse intent.
Wilson (CTO) calls himself the Chief Meme Officer and runs it on the simple theory (but effective) that a developer âbuysâ a backend once (the moment a project starts) and its hard to catch that exact moment.
Hereâs how they did it: