By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
- 0:04 – 2:05
Supabase Select headlines: introducing long-running Supabase Compute
The host opens by framing the episode around upcoming announcements at Supabase Select. Paul Copplestone introduces Supabase Compute as a way to run longer workloads than Edge Functions, with serverless compute colocated on the same private network as the database.
- •The conversation is recorded ahead of Supabase Select, with announcements previewed for release after the event
- •Paul Copplestone explains Edge Functions have a two-second limit and users want longer-running workloads
- •Supabase Compute is presented as long-running, serverless compute colocated with the database for low latency
- •Compute can run full containers and is no longer constrained to Deno; languages like Rust and Python are mentioned
- •Paul compares it to container-style Lambda functions
- 2:05 – 3:24
AurionDB beta: faster Postgres storage engine and open-source licensing
Paul Copplestone describes AurionDB as a drop-in replacement for Postgres’s heap storage engine focused on performance and efficiency. He details the compatibility and reliability testing they ran and says it will be released in beta with an Apache 2 license and patent coverage.
- •AurionDB is positioned as one of three database innovations: performance, scaling up, and scaling out
- •Paul says AurionDB is a drop-in replacement for Postgres heap and runs about 1.5–2x faster with no changes required
- •He says it reduces or removes needs for background tasks like vacuum and issues like bloat
- •He lists extensive testing efforts: pgregress compatibility, antithesis, TPCC nightly benchmarks, and Jepson to ensure it cannot lose data
- •He says the technology was acquired, further developed, patented, and released under Apache 2 with patent coverage
- 3:24 – 5:00
Multigress: a new Postgres operator to prevent data loss and enable sharding
Paul Copplestone introduces Multigress as a ground-up rewrite of a Postgres operator after finding data-loss scenarios across existing operators. He explains rigorous failover testing, an open-source release, and a compatibility-first approach toward eventual sharding.
- •Paul defines operators as tools to manage multi-node Postgres clusters for failover and backups
- •He says Supabase found every operator they evaluated could lose data under certain conditions
- •Multigress is presented as a rebuilt operator/“operating system,” tested with 1,000 sequential failovers without data loss
- •Release details include open source availability and an invite-only path for serious workloads on Supabase’s platform
- •In response to the host’s Vitess comparison, Paul says the design prioritizes compatibility first so sharding won’t require query or code changes
- 5:00 – 7:15
Roadmap and ecosystem framing: sharding timeline and design partners
The discussion continues on how Multigress relates to sharding and why compatibility is central. Paul Copplestone provides a rough timeline and mentions design partners working with Supabase on scaling needs.
- •Paul clarifies sharding is not released yet and suggests some parts could land early next year, depending on platform priorities
- •The host frames sharding as a key missing piece for large-scale Postgres adoption; Paul emphasizes it’s for the broader open-source community, not just Supabase customers
- •Paul mentions a design partner program and names organizations working with them, including Booz Allen, Postman, and Perplexity
- •The host emphasizes the importance of a sharding layer if workloads shift to Postgres
- •Paul reiterates Multigress aims to help anyone running Postgres at scale
- 7:15 – 10:08
Scaling out: acquiring Turso and building “agentic databases” for billions of instances
Paul Copplestone explains the need to scale from millions to billions of databases per month and introduces the acquisition of Turso. The conversation explores Turso’s SQLite-based architecture and why file-format-style databases fit the “many tiny databases” future.
- •Paul says Supabase launches about 5 million databases per month and anticipates needing to launch billions per month in the future
- •He announces Supabase has acquired Turso to help power “agentic databases”
- •They discuss SQLite’s single-writer limitation and how Turso built MVCC-like capabilities to support multiple writers, including forking due to licensing concerns
- •Paul connects new database architectures to innovations in object storage (durability and features) while noting limitations for large transactional workloads
- •He explains the idea that billions of small databases may need to behave more like a file format, making SQLite particularly interesting
- 10:08 – 13:01
Product packaging: keeping the Turso brand and launching Supabase Spark for prototypes
Paul Copplestone outlines how Supabase will position Turso and a new Supabase instance type for small projects. He describes a pathway where users start small and upgrade through Postgres and eventually Multigress as traction grows.
- •Paul says Supabase will keep the Turso brand focused on SQLite
- •He introduces a smaller Supabase instance type called Supabase Spark, compatible with Supabase libraries
- •He frames Spark as enabling “one database for any idea” and a smoother upgrade path to full Postgres and then Multigress
- •He emphasizes the need for smooth migration between backends, including zero-downtime migrations, as projects gain traction
- •The host and Paul discuss that many of these new databases start tiny and only later demand large scale
- 13:01 – 17:34
Community, memes, and early growth loops: Twitter strategy and Hacker News dynamics
The conversation shifts to Supabase’s marketing and community voice, especially memes and Hacker News. The host and Ant Wilson recall how Supabase’s social strategy was analyzed publicly and how they learned to navigate perceptions of YC/Hacker News bias.
- •Ant Wilson and the host discuss Supabase’s meme culture and the difficulty of hiring for developer-humor marketing
- •They recall someone posting an analysis of Supabase’s Twitter strategy to Hacker News and how Supabase used it internally for onboarding marketing
- •They discuss getting scolded for launching too many things and for publicly celebrating front-page Hacker News placements
- •Ant describes why screenshotting front-page Hacker News success can look like gloating or bias
- •They point to Hacker News as an important early growth driver while acknowledging reputational sensitivities
- 17:34 – 20:45
Origin story pivot: from “real-time Postgres” to “open source Firebase alternative” (and scaling pains)
Ant Wilson and Paul Copplestone recount how a Hacker News post they didn’t plan accelerated Supabase’s trajectory. They describe the early tagline change, the initial infrastructure setup on DigitalOcean, and the rapid migration to AWS after user growth.
- •Ant says Supabase initially positioned as “real-time Postgres,” based on a real-time engine he built; he says “no one cared” until they reframed as an open source Firebase alternative
- •They recount being launched on Hacker News by someone else before they felt ready
- •Ant describes early architecture where each new database meant two DigitalOcean droplets (database + APIs) to decouple upgrades
- •Paul says they went from eight users to 800 from that launch and burned through DigitalOcean credits quickly
- •They describe migrating 800 databases to AWS in their first week of YC after DigitalOcean wouldn’t extend additional credits
- 20:45 – 23:22
Compute shortages, multi-cloud pressure, and bringing on CapitalG
The host asks about CPU shortages and scaling capacity. Paul Copplestone describes close planning with AWS, higher costs, and the announcement of a new investment partner, CapitalG, tying it to future multi-cloud needs and closer partnerships with AI labs.
- •They discuss broader compute constraints and capacity planning as Supabase grows
- •Paul says Supabase meets with AWS frequently and must plan closely and pay more to secure capacity
- •He announces a new investment partner, CapitalG, and describes it as providing access to the Alphabet ecosystem
- •He ties this to needing more compute and considering a multi-cloud strategy, with GCP described as an obvious option
- •They discuss object storage features (including strong consistency and S3 Express) and why caches like Redis still matter
- 23:22 – 30:00
AI-driven growth and funnel changes: embeddings, vibe coding, and agent-assisted activation
Ant Wilson and Paul Copplestone describe changes in customer behavior driven by AI tools and “vibe coding.” They outline three “chapters” of AI impact on Supabase and explain why activation and paid conversion rose with more consumer-like top-of-funnel traffic.
- •Ant says customers now monetize faster, citing projects generating serious revenue within a week due to easier integration (including Stripe at the agentic layer)
- •Paul frames three AI chapters: embeddings (promoting Postgres vector capabilities), vibe coding adoption, and a more recent wave driven by better models increasing sign-ups
- •Paul says Supabase spends little on marketing and attributes much to memes and community
- •Ant notes conversion and activation typically drop with consumer-like traffic, but for Supabase both went up
- •Paul attributes this to agents handling signup-to-activation in one step and says those users converted to paid at higher rates than traditional developer users
- 30:00 – 35:39
Community ownership: giving stock to community legends and scaling support knowledge
Ant Wilson shares a plan to involve the community more deeply by giving away stock rather than running a complex crowdfunding round. They highlight a community member’s contributions and discuss strategies to make support knowledge reusable beyond private chat platforms.
- •Ant explains legal hurdles with crowdfunding and the eventual mechanism: giving stock away instead of taking investments
- •He says Supabase earmarked $1 million in stock to distribute to community members
- •They spotlight Gary Abbott (known in the Supabase Discord as Gary Austin) and cite his volume and speed of answering questions
- •The host raises concerns about Discord’s lack of public, searchable knowledge; Ant explains they chose to be present across multiple community platforms
- •Paul describes scraping common Q&A into GitHub Discussions and mirroring it onto their website, using GitHub as a CMS to surface repeated answers
- 35:39 – 40:44
Enterprise and “product-led sales”: triggers, scripts, and greenfield strategy
Paul Copplestone explains Supabase’s approach to sales as product-led and trigger-driven rather than traditional selling. He argues that database migrations are rare, so the focus is landing new workloads (especially in enterprise) and expanding over time, with Control Tower supporting fleets of databases.
- •Paul describes Supabase as a developer-first company focused on maintaining developer love while moving upmarket, citing Stripe as a role model
- •He explains product-led sales using product triggers (errors, scaling limits, spend, important logos) and measuring cohorts against a control group
- •He describes using traffic patterns and AI-generated scripts so sales calls focus on helping users; he says they measure incremental uplift from those interventions
- •He states enterprises usually want to launch many databases rather than migrate an existing production OLTP database; he says migrations “almost never” happen
- •He introduces Control Tower as a fleet management view for enterprises and ties it to capabilities built for Supabase for Platforms
- 40:44 – 45:02
Database stickiness, migrations risk, and why OLTP cutovers are hard
The host probes stickiness between frontend “vibe coding” tools and Supabase, and they discuss why databases are harder to swap. Paul Copplestone explains practical risks of OLTP migrations, including downtime costs and split-brain concerns, and how teams often phase changes by starting new workloads.
- •Paul argues running databases is hard and migrating databases is harder than switching front-end tools
- •He credits Lovable with early “skills” that prevented agents from doing unsafe database actions (like turning off RLS or misusing Postgres for images)
- •The host raises the idea of Supabase as a potential “new RDS” and asks about bigger migration opportunities like Oracle
- •Paul explains OLTP migration risk: downtime directly impacts revenue and parallel-run cutovers create split-brain reconciliation challenges
- •He says many teams instead split off new workloads over time rather than migrate the core OLTP system all at once
- 45:02 – 48:15
HTAP and analytics: interest in DuckDB/Duck Lake, but separate OLTP scaling via sharding
The host asks about HTAP (combining transactional and analytical workloads). Paul Copplestone says Supabase is interested in DuckDB and Duck Lake concepts but expresses skepticism about smashing OLTP and analytics together, emphasizing sharding for OLTP scale and different approaches for analytics.
- •Paul says Supabase is particularly interested in Duck Lake and describes DuckDB as “a SQLite for analytics” that can read from object storage and from Postgres
- •He mentions DuckDB Labs and describes efforts to build a foundation/committee around open source governance
- •Paul states Supabase’s focus is using the right tech for the job rather than making Postgres an analytical database
- •He says at OLTP scale, sharding is the best way to scale into petabytes due to limits on NVMe and performance issues if transactional access relies on object storage
- •He concludes that combining OLTP and analytics into a single HTAP system may not make sense in his view
- 48:15 – 53:05
Durable workflows, lab partnerships, and scaling to model-driven traffic
They connect long-running compute to durable workflows and discuss partnering with frontier AI labs. Paul Copplestone explains the need to scale to enormous database-provisioning demands if models make database creation ubiquitous, tying back to the Turso acquisition and scaling-out strategy.
- •The host asks why durable workflows haven’t been a top priority; Paul says the missing primitive was long-running compute due to the previous two-second timeout
- •Paul says Compute unlocks the ability to build long-running durable workflows on Supabase
- •They discuss partnering with frontier labs and models, with Paul saying US labs currently drive most traffic for them
- •Paul describes an ambition to be a default backend provider for model-driven app creation, but says they previously couldn’t handle the scale
- •He uses ChatGPT as an example of enormous scale and ties the path forward to launching billions of databases per month enabled by acquiring Turso
- 53:05 – 59:06
Git-native, agent-friendly development: declarative schemas and pgDelta
Paul Copplestone describes a shift toward code-first, Git-native workflows to better support agents. He explains why historical migration logs are hard for agents to reason about and introduces declarative schema representation and a new tool called pgDelta.
- •Paul says the company is moving from dashboard-first to code-first, Git-native workflows, building on existing CLI-based workflows
- •He describes a local “Supabase folder” that represents the database, functions, and related infrastructure-as-code artifacts
- •He explains the agent problem with long migration histories: agents struggle to infer current schema across many files without slow database reconstruction
- •He says they’re making the schemas folder a fully declarative representation of the database, including tables, policies, and comments
- •He introduces pgDelta as a new library usable with any Postgres database, positioned as an important step for fast agent iteration on the filesystem
- 59:06 – 1:11:40
Founder dynamics, open-source futures, and internal AI coding spend
They close with reflections on how the founders collaborate, thoughts on open-source rewrites (including Rust), and practical internal AI usage. Paul Copplestone shares Supabase’s approximate monthly AI spend and how they think about maximizing end-to-end leverage rather than minimizing token costs.
- •Asked what they disagree on, Ant says disagreements resolve quickly and rarely become major because most issues aren’t worth fighting over and they’re busy owning different areas
- •They recount shared history from Entrepreneur First in Singapore and how a house of technical builders led to effective pairing and early hiring
- •On open source, Paul suggests many tools may consolidate via rewrites (often into Rust) but warns against wasting “innovation tokens” rewriting everything repeatedly
- •Ant explains Supabase teams are decentralized in tool choices; Paul says they can query internal documentation to understand spend and reports about $300K/month on AI tools
- •They discuss uneven AI usage across employees and emphasize focusing on end-to-end process compression rather than being ashamed of spending levels
