CHAPTERS
- 0:05 – 1:56
Paul Copplestone’s founder journey and lessons from earlier startups
Paul shares his background as a multi-time founder and how earlier, less-successful ventures shaped the way he built Supabase. The key takeaway is that failures compound into better judgment—especially when building something as complex as a database company.
- •Supabase is Paul’s third venture-backed startup (with additional non-venture projects)
- •Earlier startups in Southeast Asia were not “big exits,” but were highly formative
- •Failure can be a stronger teacher than success in startup building
- •Supabase is a “full circle” moment: enabling others to launch startups is part of his personal arc
- 1:56 – 3:11
Building the tool he wished existed: databases, real-time, and early career roots
Paul traces Supabase’s origins to his early database-focused contracting work, including building real-time systems long before today’s tooling existed. Supabase is positioned as modern “primitives” for problems he faced 10–15 years earlier.
- •Paul’s career began with database-heavy contracting work starting at university
- •Early real-time system work (e.g., for farmers in New Zealand) influenced Supabase’s direction
- •The tech existed (e.g., ColdFusion era) but not in a modern, developer-friendly form
- •Supabase aims to package these primitives in a way developers can use today
- 3:11 – 4:27
Why bet on Postgres (even if it’s 30 years old)?
Supabase intentionally chose Postgres because Paul saw early signals of developer preference and momentum—especially among early adopters. The age of Postgres is framed as a strength: decades of community hardening and ecosystem maturity.
- •They knew they wanted to build a database company because ‘big, hairy problems’ create opportunity
- •Hacker News served as an early indicator of Postgres adoption trends
- •Postgres’ popularity grew into mainstream dominance over time
- •Supabase views itself as adding fuel to a community-driven movement, not creating it alone
- 4:27 – 6:45
‘Real’ open source from day one: philosophy, flywheels, and ecosystem-building
Paul explains that the decision to open source wasn’t a tactical marketing move—it was a philosophical alignment with how Postgres itself thrives. Supabase’s strategy emphasizes contributing to and assembling an ecosystem around Postgres rather than creating a proprietary ‘Postgres-like’ database.
- •Open source decision was largely instinctive and values-driven
- •Postgres ‘belongs to no one,’ enabling durable long-term adoption and contributions
- •Hyperscalers offering Postgres strengthens the ecosystem flywheel
- •Supabase prefers contributing to existing OSS tools; only builds new ones when needed
- •Licenses are permissive (MIT/Apache 2/Postgres), avoiding ‘fake open source’ patterns
- 6:45 – 8:33
Cloud giants, open core, and why Supabase isn’t easy to clone as a service
The conversation addresses a classic OSS fear: hyperscalers monetizing your work. Paul argues the threat is reduced because Supabase competes with cloud providers’ own Postgres offerings and because Supabase is an integrated suite—not a single easy-to-host component.
- •Supabase avoided an open-core upsell model; managed Postgres is inherently hard to run solo
- •Backups, failovers, and operational complexity drive customers toward managed offerings
- •Hyperscalers already sell their own Postgres flavors, making ‘reselling Supabase’ unlikely
- •Supabase is an amalgamation of multiple tools around Postgres—harder to replicate quickly
- 8:33 – 10:26
The pivotal repositioning: from ‘real-time Postgres’ to ‘open source Firebase alternative’
Paul describes the early product narrative experiments and the breakthrough moment: changing the tagline unlocked distribution and demand. A Hacker News-driven launch turned Supabase into a clear category option, even while feature parity with Firebase was still aspirational.
- •Initial traction came from a real-time engine built atop Postgres after Firebase scaling limits
- •First positioning (‘real-time Postgres’) didn’t resonate strongly at first
- •Tagline switch to ‘open source Firebase alternative’ triggered a major Hacker News surge
- •They recognized demand even while missing many features compared to Firebase
- •Supabase aimed to be database-centric while selecting a few critical primitives to build first
- 10:26 – 12:18
Winning developers over Firebase: pricing clarity, open source trust, and relational data
Supabase differentiated by addressing the pain points of Firebase: scaling risk, pricing surprises, and the NoSQL model mismatch for many apps. Open source credibility and Postgres’ relational foundation became long-term strategic advantages as the industry shifted back toward SQL.
- •‘Not Google’ positioning resonated with a developer audience
- •Avoiding bill shock via transparent pricing was a key wedge
- •Open source aligned with what Firebase’s original team reportedly wanted but couldn’t pursue at Google
- •Postgres offered relational structure vs Firebase’s NoSQL approach
- •Relational resurgence made the Postgres bet increasingly valuable over time
- 12:18 – 13:29
Launch waves, credibility building, and YC adoption over time
Supabase’s growth came in distinct ‘waves’ tied to launches (real-time, auth, alpha→beta), while credibility took time—especially as a database vendor. YC batch adoption shifted from near-zero early on to majority usage as Supabase proved reliability and developer love.
- •Growth came in waves: initial launch, auth launch, and alpha-to-beta transition
- •In their YC batch, essentially no one used Supabase—database trust takes time
- •Remote batch dynamics reduced organic internal adoption and connection effects
- •Today: ~10M developers and >60% adoption in recent YC batches
- •Developer experience became central to sustaining momentum post-launch
- 13:29 – 15:20
Developer experience as an operating metric: ‘time to value’ → agent-era outcomes
Paul explains how Supabase operationalized developer experience with a concrete metric: time from signup to first successful database interaction. As agents become common, the metric shifts from speed alone to achieving outcomes with minimal human intervention.
- •They benchmarked ‘time to value’ vs AWS: ~8 minutes vs <1 minute goal
- •Supabase reduced time to value dramatically (down to seconds)
- •AWS later prioritized similar onboarding improvements
- •Agent workflows change what ‘DX’ means: time matters less than autonomous completion
- •The new goal: results without repeated human involvement
- 15:20 – 18:13
AI impact, chapter 1: embeddings and PGVector adoption through open source contribution
The first AI wave for Supabase was the rise of embeddings and vector search. A community contributor helped add pgvector support and inspired an early ‘chat with docs’ demo—an example of open source collaboration directly creating product momentum.
- •Vector databases/embeddings created new demand for Postgres-based vector search
- •A contributor submitted a PR to add PGVector, created by Andrew Kane
- •Supabase used this to demo RAG by embedding documentation and enabling doc chat
- •They were early and cautious due to hallucinations; launched with a ‘Clippy’ framing
- •PGVector became a standard as AWS and others adopted it
- 18:13 – 21:12
AI impact, chapter 2: vibe-coding platforms and the ‘Supabase for Platforms’ product
The second wave came from vibe-coding tools (e.g., Lovable, Bolt) that rapidly spun up massive numbers of small databases—initially looking like an attack or unsustainable usage. Supabase leaned in based on a long-term thesis: win developers at the start and keep them forever, enabling platform-native Supabase usage.
- •End of 2024 saw unusual spikes: tens of thousands/hundreds of thousands of DB launches
- •Initial confusion: prototypes and tiny DBs didn’t match traditional revenue patterns
- •Strategic thesis: to build a generational database company, be there at the start
- •Supabase created ‘Supabase for Platforms’ so other products can build atop Supabase
- •Platform product grew to 50+ customers, including large players and enterprise internal labs
- 21:12 – 23:46
AI impact, chapter 3: Claude Code and agent-driven acceleration across every funnel metric
The third wave felt structurally different: Claude Code increased not just top-of-funnel signups but also activation, conversion to paid, and downstream success. Paul frames this as high-intent builders moving faster without Supabase spending on marketing, with agents launching a majority of databases.
- •Claude Code drove simultaneous increases in activation, conversion, and revenue curves
- •Users got to ‘production and paying’ within ~a day in the average profile described
- •Acceleration wasn’t marketing-driven; audience quality stayed high
- •Measured: 60%+ of databases launched by agents (likely undercounted)
- •Agent launches via CLI reduce observability of whether a human or agent performed actions
- 23:46 – 27:04
Tooling for an agent-first world: MCP/CLI-first, Git workflows, and dashboard parity
As agents do more of the building, Supabase’s product surface must shift from dashboard-first to code-first. Paul describes the need for first-class CLI/MCP experiences and a bidirectional sync between dashboard actions and code representations (the ‘Supabase folder’).
- •Agent-era tooling requires MCP and CLI to be first-class citizens
- •Dashboard remains used, but its relative importance is declining
- •Need strong Git-native workflows to represent infrastructure/config as code
- •Supabase aims for lockstep parity: dashboard changes reflected in code and vice versa
- •In the future, model defaults may matter as much as developer preference
- 27:04 – 31:17
Scaling the company: from ‘hair-on-fire hiring’ to reliability, process, and parallel execution
Paul explains how operational reality changes at scale: the roadmap gets interrupted by reliability work, partnerships, and unexpected constraints. Supabase grew rapidly from ~220 to ~360 people, shifting from a single-company cadence (launch weeks/defrag) to parallel modes across teams.
- •Early hiring rule: only hire for ‘hair on fire’ problems
- •Scaling introduces unexpected constraints (support load, IP exhaustion, operational issues)
- •Company shifts from ‘order maker’ (push roadmap) to ‘order taker’ (incoming demands)
- •Headcount grew from ~220 to ~360 within the year to support growth
- •Old cadence: launch week then ‘defrag’; now requires both in parallel with nuanced team structures
- 31:17 – 38:15
AI inside Supabase: distributed-by-default knowledge, AI-enabled BizOps, and measurable automation
Because Supabase has always been distributed, much of the company’s history is written down—making it unusually amenable to AI tooling. Paul describes moving toward AI-enabled BizOps, end-to-end automation (where real gains occur), and examples like self-serve analytics via Hex.
- •Distributed across 60+ countries; work artifacts live in Slack/Notion with deep history
- •Company context becomes queryable, improving onboarding and decision recall
- •Focus is on end-to-end automation; partial automation still leaves humans as bottlenecks
- •Hex + data warehouse agent enables company-wide Q&A, tripling query volume vs old workflows
- •Aim to centralize operating workflows (e.g., Linear) to enable broader agent execution beyond engineering
- 38:15 – 41:43
Funding and staying grounded: operating capital, YC mindset, and advice for devtool founders
Paul frames the $500M round as operational fuel rather than proof of success, emphasizing that fundraising is a meta-process. He closes with pragmatic advice: be prolific, identify what works, push relentlessly, and acknowledge luck as a real ingredient.
- •Large rounds provide operating capital to bridge time between DB creation and customer payment
- •‘Cash does not equal success’—fundraising isn’t the product or the outcome
- •Supabase exists despite competitors having more cash; execution and focus matter most
- •Culture and grounding flow from founders; transparency and principled operations reinforce it
- •Advice: try many things, double down on what works, be relentless—and expect luck to matter
