Database School

Marcel Kornacker, the creator of Apache Impala and co-creator of Apache Parquet, joins me to talk about his latest project: Pixeltable, a multimodal AI database that combines structured and unstructured data with rich, Python-native workflows.

From ingestion to vector search, transcription to snapshots, Pixeltable eliminates painful data plumbing for modern AI teams.

Follow Marcel

• Pixeltable: https://pixeltable.com
• Pixeltable GitHub: https://github.com/pixeltable/pixeltable
• LinkedIn: https://www.linkedin.com/in/marcelkornacker

Follow Aaron

• Twitter: https://twitter.com/aarondfrancis
• LinkedIn: https://www.linkedin.com/in/aarondfrancis
• Website: https://aaronfrancis.com – find articles, podcasts, courses, and more
• Database School: https://databaseschool.com

Chapters

• 0:00 – Introduction
• 0:20 – Meet Marcel Kornacker
• 1:19 – Early career and grad school in databases
• 2:12 – Joining Google and building F1
• 3:42 – How F1 used Spanner at Google
• 4:01 – Starting Apache Impala at Cloudera
• 6:02 – Why SQL still matters
• 7:29 – What keeps Marcel fascinated with databases
• 9:37 – The “SQL is dead” waves and shift to AI
• 10:21 – Observing pain points in computer vision pipelines
• 13:02 – Multimodal data challenges and the idea for Pixeltable
• 16:10 – How Pixeltable handles transformations with computed columns
• 26:29 – Example: processing video, audio, and transcripts in Pixeltable
• 33:12 – DAG execution and parallelism explained
• 37:00 – Transactional guarantees in Pixeltable
• 39:00 – Iterators and chunking data for search
• 42:26 – Using embeddings and semantic search
• 47:05 – Updating data and incremental recomputation
• 50:06 – Thoughts on RAG and hybrid search
• 53:14 – Real-world use cases and dataset curation
• 57:00 – Example: labeling food waste on cruise ships
• 1:02:00 – Labeling workflows and syncing annotations
• 1:02:41 – Pixeltable’s roadmap and cloud vision
• 1:07:10 – How to get involved with Pixeltable
• 1:09:03 – Closing and where to find Marcel

I chat with Lev Kokotov to talk about building PgDog, an open-source sharding solution for Postgres that sits outside the database. Lev shares the journey from creating PgCat to launching PgDog through YC, the technical challenges of sharding, and why he believes scaling Postgres shouldn’t require extensions or rewrites.

Follow Lev:

• Twitter: https://twitter.com/levpgdog
• PgDog: https://pgdog.dev

Follow Aaron:

• Twitter: https://twitter.com/aarondfrancis
• LinkedIn: https://www.linkedin.com/in/aarondfrancis
• Website: https://aaronfrancis.com — find articles, podcasts, courses, and more.
• Database School: https://databaseschool.com

Chapters

• 00:00 - Intro
• 01:27 - Lev’s self-taught to computer science degree journey
• 04:50 - Transition to Postgres discussion
• 05:24 - History of PgCat
• 07:06 - What PG Cat does and key features
• 08:59 - Why Lev built PgCat instead of extending PG Bouncer
• 10:06 - PG Cat’s current status and usage
• 12:20 - Moving from PgCat to PgDog
• 13:09 - Applying to YC as a solo founder
• 16:24 - YC pitch: the market gap for Postgres sharding
• 18:52 - High-level overview of PgDog
• 23:32 - Why PgDog is not an extension
• 25:57 - When to build Postgres extensions vs standalone tools
• 27:49 - PgDog architecture and query parsing
• 30:39 - Handling cross-shard queries and current capabilities
• 33:47 - How PgDog shards an existing large Postgres database
• 36:37 - Parallel replication streams for faster sharding
• 39:07 - Alternate resharding approaches
• 42:52 - Where PgDog draws the orchestration line
• 44:00 - Vision for PgDog Cloud vs bring-your-own-database
• 46:47 - Company status: first hire, design partners, and production use
• 50:45 - How deploys work for customers
• 52:20 - Importance of building closely with design partners
• 54:05 - Paid design partnerships and initial deployments
• 56:23 - Benefit of sitting outside Postgres for compatibility
• 58:32 - Near-term roadmap and long-term vision
• 1:01:03 - Where to find Lev online

Want to learn more about SQLite?  
Check out my course on SQLite: https://highperformancesqlite.com/?ref=yt  

In this episode of Database School, I chat with Glauber Costa, CEO of Turso, about their audacious decision to rewrite SQLite from the ground up.  

We cover the technical motivations, open contribution philosophy, and how deterministic simulation testing is unlocking new levels of reliability.  

Get your free SQLite reference guide: https://highperformancesqlite.com/products/sqlite-reference-guide.  

Follow Glauber:  
Twitter: https://twitter.com/glcst  
Turso: https://tur.so/af  

Follow Aaron:  
Twitter: https://twitter.com/aarondfrancis  
LinkedIn: https://www.linkedin.com/in/aarondfrancis  
Website: https://aaronfrancis.com - find articles, podcasts, courses, and more.  

Database school: https://databaseschool.com  

Chapters:  
00:00 - Intro to guest Glauber Costa  
00:58 - Glauber's background and path to databases  
02:23 - Moving to Texas and life changes  
05:32 - The origin story of Turso  
07:55 - Why fork SQLite in the first place?  
10:28 - SQLite’s closed contribution model  
12:00 - Launching libSQL as an open contribution fork  
13:43 - Building Turso Cloud for serverless SQLite  
14:57 - Limitations of forking SQLite  
17:00 - Deciding to rewrite SQLite from scratch  
19:08 - Branding mistakes and naming decisions  
22:29 - Differentiating Turso (the database) from Turso Cloud  
24:00 - Technical barriers that led to the rewrite  
28:00 - Why libSQL plateaued for deeper improvements  
30:14 - Big business partner request leads to deeper rethink  
31:23 - The rewrite begins  
33:36 - Early community traction and GitHub stars  
35:00 - Hiring contributors from the community  
36:58 - Reigniting the original vision  
39:40 - Turso’s core business thesis  
42:00 - Fully pivoting the company around the rewrite  
45:16 - How GitHub contributors signal business alignment  
47:10 - SQLite’s rock-solid rep and test suite challenges  
49:00 - The magic of deterministic simulation testing  
53:00 - How the simulator injects and replays IO failures  
56:00 - The role of property-based testing  
58:54 - Offering cash for bugs that break data integrity  
1:01:05 - Deterministic testing vs traditional testing  
1:03:44 - What it took to release Turso Alpha  
1:05:50 - Encouraging contributors with real incentives  
1:07:50 - How to get involved and contribute  
1:20:00 - Upcoming roadmap: indexes, CDC, schema changes  
1:23:40 - Final thoughts and where to find Turso

Sugu Sougoumarane, co-creator of Vitess and co-founder of PlanetScale, joins me to talk about his time scaling YouTube’s database infrastructure, building Vitess, and his latest project bringing sharding to Postgres with Multigres.

This was a fun conversation with technical deep-dives, lessons from building distributed systems, and why he’s joining Supabase to tackle this next big challenge.

Sugu’s Vitess videos:

https://www.youtube.com/watch?v=6yOjF7qhmyY&list=PLA9CMdLbfL5zHg3oapO0HvtPfVx6_iJy6

The big announcement:

https://supabase.com/blog/multigres-vitess-for-postgres

Database School:

https://databaseschool.com

Follow Sugu:

Twitter: https://twitter.com/ssougou

LinkedIn: https://www.linkedin.com/in/sougou

Follow Aaron:

Twitter: https://twitter.com/aarondfrancis

LinkedIn: https://www.linkedin.com/in/aarondfrancis

Website: https://aaronfrancis.com - find articles, podcasts, courses, and more.

Chapters:

00:00 - Intro

1:38 - The birth of Vitess at YouTube

3:19 - The spreadsheet that started it all

6:17 - Intelligent query parsing and connection pooling

9:46 - Preventing outages with query limits

13:42 - Growing Vitess beyond a connection pooler

16:01 - Choosing Go for Vitess

20:00 - The life of a query in Vitess

23:12 - How sharding worked at YouTube

26:03 - Hiding the keyspace ID from applications

33:02 - How Vitess evolved to hide complexity

36:05 - Founding PlanetScale & maintaining Vitess solo

39:22 - Sabbatical, rediscovering empathy, and volunteering

42:08 - The itch to bring Vitess to Postgres

44:50 - Why Multigres focuses on compatibility and usability

49:00 - The Postgres codebase vs. MySQL codebase

52:06 - Joining Supabase & building the Multigres team

54:20 - Starting Multigres from scratch with lessons from Vitess

57:02 - MVP goals for Multigres

1:01:02 - Integration with Supabase & database branching

1:05:21 - Sugu’s dream for Multigres

1:09:05 - Small teams, hiring, and open positions

1:11:07 - Community response to Multigres announcement

1:12:31 - Where to find Sugu

In this episode, I chat with Richard Crowley from PlanetScale about their new offering: PlanetScale Metal.

We dive deep into the performance and reliability trade-offs of EBS vs. locally attached NVMe storage,

and how Metal delivers game-changing speed for MySQL workloads.

Links:

• Database School: https://databaseschool.com
• PlanetScale: https://planetscale.com
• PlanetScale Metal: https://planetscale.com/blog/announcing-metal

Follow Richard:

• Twitter: https://twitter.com/rcrowley
• Website: https://rcrowley.org

Follow Aaron:

• Twitter: https://twitter.com/aarondfrancis
• LinkedIn: https://www.linkedin.com/in/aarondfrancis
• Website: https://aaronfrancis.com — find articles, podcasts, courses, and more.

Chapters:

00:00 - Intro: What is PlanetScale Metal?

00:39 - Meet Richard Crowley

01:33 - What is Vitess and how does it work?

03:00 - Where PlanetScale fits into the picture

09:03 - Why EBS is the default and its trade-offs

13:03 - How PlanetScale handles durability without EBS

16:03 - The engineering work behind PlanetScale Metal

22:00 - Deep dive into backups, restores, and availability math

25:03 - How PlanetScale replaces instances safely

27:11 - Performance gains with Metal: Latency and IOPS explained

32:03 - Database workloads that truly benefit from Metal

39:10 - The myth of the infinite cloud

41:08 - How PlanetScale plans for capacity

43:02 - Multi-tenant vs. PlanetScale Managed

44:02 - Who should use Metal and when?

46:05 - Pricing trade-offs and when Metal becomes cheaper

48:27 - Scaling vertically vs. sharding

49:57 - What’s next for PlanetScale Metal?

53:32 - Where to learn more

Johannes Schickling, original founder of Prisma, joins me to talk about LiveStore, his ambitious local-first data layer designed to rethink how we build apps from the data layer up.

We dive deep into event sourcing, syncing with SQLite, and why this approach might power the next generation of reactive apps.

🔗 Links Mentioned

Want to learn more about SQLite?

Check out my SQLite course:

https://highperformancesqlite.com/?ref=yt

LiveStore

Website: https://livestore.dev

Repo: https://github.com/livestorejs

Discord: https://discord.gg/RbMcjUAPd7

Follow Johannes

Twitter: https://www.x.com/schickling

LinkedIn: https://www.linkedin.com/in/schickling

Website: https://www.schickling.dev

Podcast: https://www.localfirst.fm

Follow Aaron

Twitter: https://twitter.com/aarondfrancis

LinkedIn: https://www.linkedin.com/in/aarondfrancis

Website: https://aaronfrancis.com — find articles, podcasts, courses, and more

Database School

YouTube: https://www.youtube.com/playlist?list=PLI72dgeNJtzqElnNB6sQoAn2R-F3Vqm15

Audio only: https://databaseschool.transistor.fm

🕒 Chapters

00:00 - Intro to Johannes

01:00 - From Prisma to LiveStore

03:00 - Discovering local-first through Riffle

05:00 - What is local-first and who is it for?

07:00 - Why local-first is gaining popularity

10:00 - The inspiration from apps like Linear

13:00 - Gaps in local-first tooling in 2020

16:00 - Social apps vs. user-centric apps

18:00 - Distributed systems and why they’re hard

21:00 - The value of embracing local-first

24:00 - What LiveStore is and what it’s not

26:00 - Event sourcing as the core of LiveStore

30:00 - Benefits of event sourcing for apps

33:00 - Schema changes and time travel via events

37:00 - Materializers and how they work

43:00 - Syncing data across clients and devices

48:00 - Sync servers and cross-tab communication

54:00 - Architecture choices and dev tooling

59:00 - State of the project and future vision

1:06:00 - How to get involved

Josh Howard, Senior Engineering Manager at Cloudflare, joins me to explain how Durable Objects and D1 work under the hood—and why Cloudflare’s approach to stateful serverless infrastructure is so unique. We get into V8 isolates, replication models, routing strategies, and even upcoming support for containers. 

Want to learn more about SQLite? Check out my SQLite course: https://highperformancesqlite.com/?ref=podcast 

Follow Josh: 
Twitter: https://twitter.com/ajoshhoward 
LinkedIn: https://www.linkedin.com/in/joshthoward 

Follow Aaron: 
Twitter: https://twitter.com/aarondfrancis 
LinkedIn: https://www.linkedin.com/in/aarondfrancis 
Website: https://aaronfrancis.com - find articles, podcasts, courses, and more.

Database school on YouTube: https://www.youtube.com/playlist?list=PLI72dgeNJtzqElnNB6sQoAn2R-F3Vqm15
Database school audio only: https://databaseschool.transistor.fm 

Chapters 
00:00 - Intro 
00:37 - What is a Durable Object? 
01:43 - Cloudflare’s serverless model and V8 isolates 
03:58 - Why stateful serverless matters 
05:14 - Durable Objects vs Workers 
06:22 - How routing to Durable Objects works 
08:01 - What makes them "durable"? 
08:51 - Tradeoffs of colocating compute and state 
10:58 - Stateless Durable Objects 
12:49 - Waking up from sleep and restoring state 
16:15 - Durable Object storage: KV and SQLite APIs 
18:49 - Relationship between D1, Workers KV, and DOs 
20:34 - Performance of local storage writes 
21:50 - Storage replication and output gating 
24:15 - Lifecycle of a request through a Durable Object 
26:46 - Replication strategy and long-term durability 
31:25 - Placement logic and sharding strategy 
36:35 - Use cases: agents, multiplayer games, chat apps 
40:33 - Scaling Durable Objects 
41:14 - Globally unique ID generation 
43:22 - Named Durable Objects and coordination 
46:07 - D1 vs Workers KV vs Durable Objects 
47:50 - Outerbase acquisition and DX improvements 
49:49 - Querying durable object storage 
51:20 - Developer Week highlights and new features 
52:44 - Read replicas and sticky sessions 
53:49 - Containers and the future of routing 
56:47 - Deployment regions and infrastructure expansion 
57:43 - Hiring and how to connect with Josh

In this episode of Database School, I talk with Heikki Linnakangas, co-founder of Neon and longtime PostgreSQL hacker, to talk about 20+ years in the Postgres community, the architecture behind Neon, and the future of multi-threaded Postgres. From paternity leave patches to branching production databases, we cover a lot of ground in this deep-dive conversation. 

Links: 
Let's make postgres multi-threaded: https://www.postgresql.org/message-id/31cc6df9-53fe-3cd9-af5b-ac0d801163f4%40iki.fi 
Hacker News discussion: https://news.ycombinator.com/item?id=36284487 

Follow Heikki: 
LinkedIn: https://www.linkedin.com/in/heikki-linnakangas-6b58bb203/ 
Website: https://neon.tech 

Follow Aaron: 
Twitter: https://twitter.com/aarondfrancis 
LinkedIn: https://www.linkedin.com/in/aarondfrancis 
Website: https://aaronfrancis.com - find articles, podcasts, courses, and more.

Database school on YouTube: https://www.youtube.com/playlist?list=PLI72dgeNJtzqElnNB6sQoAn2R-F3Vqm15
Database school audio only: https://databaseschool.transistor.fm 

00:00 - Introduction and Heikki's background 
01:19 - How Heikki got into Postgres 
03:17 - First major patch: two-phase commit 
04:00 - Governance and decision-making in Postgres 
07:00 - Committer consensus and decentralization 
09:25 - Attracting new contributors 
11:25 - Founding Neon with Nikita Shamgunov 
13:01 - Why separation of compute and storage matters 
15:00 - Write-ahead log and architectural insights 
17:03 - Early days of building Neon 
20:00 - Building the control plane and user-facing systems 
21:28 - What "serverless Postgres" really means 
23:39 - Reducing cold start time from 5s to 700ms 
25:05 - Storage architecture and page servers 
27:31 - Who uses sleepable databases 
28:44 - Multi-tenancy and schema management 
31:01 - Role in low-code/AI app generation 
33:04 - Branching, time travel, and read replicas 
36:56 - Real-time point-in-time query recovery 
38:47 - Large customers and scaling in Neon 
41:04 - Heikki’s favorite Neon feature: time travel 
41:49 - Making Postgres multi-threaded 
45:29 - Why it matters for connection scaling 
50:50 - The next five years for Postgres and Neon 
52:57 - Final thoughts and where to find Heikki

Want to learn more SQLite? Check out my SQLite course: https://highperformancesqlite.com 

In this episode, Carl Sverre and I discuss why syncing everything is a bad idea and how his new project, Graft, makes edge-native, partially replicated databases possible. We dig into SQLite, object storage, transactional guarantees, and why Graft might be the foundation for serverless database replicas. 

SQLSync: https://sqlsync.dev 
Stop syncing everything blog post: https://sqlsync.dev/posts/stop-syncing-everything 
Graft: https://github.com/orbitinghail/graft 

Follow Carl: 
Twitter: https://twitter.com/carlsverre 
LinkedIn: https://www.linkedin.com/in/carlsverre 
Website: https://carlsverre.com/ 

Follow Aaron: Twitter: https://twitter.com/aarondfrancis 
LinkedIn: https://www.linkedin.com/in/aarondfrancis 
Website: https://aaronfrancis.com - find articles, podcasts, courses, and more.

Database school on YouTube: https://www.youtube.com/playlist?list=PLI72dgeNJtzqElnNB6sQoAn2R-F3Vqm15
Database school audio only: https://databaseschool.transistor.fm  

Chapters: 00:00 - Intro and Carl’s controversial blog title
01:00 - Why “stop syncing everything” doesn't mean stop syncing
02:30 - The problem with full database syncs
03:20 - Quick recap of SQL Sync and multiplayer SQLite
04:45 - How SQL Sync works using physical replication
06:00 - The limitations that led to building Graft
09:00 - What is Graft? A high-level overview
16:30 - Syncing architecture: how Graft scales
18:00 - Graft's stateless design and Fly.io integration
20:00 - S3 compatibility and using Tigris as backend
22:00 - Latency tuning and express zone support
24:00 - Can Graft run locally or with Minio?
27:00 - Page store vs meta store in Graft
36:00 - Index-aware prefetching in SQLite
38:00 - Prefetching intelligence: Graft vs driver
40:00 - The benefits of Graft's architectural simplicity
48:00 - Three use cases: apps, web apps, and replicas
50:00 - Sync timing and perceived latency
59:00 - Replaying transactions vs logical conflict resolution
1:03:00 - What’s next for Graft and how to get involved
1:05:00 - Hacker News reception and blog post feedback
1:06:30 - Closing thoughts and where to find Carl

Prisma started as a GraphQL backend and pivoted into one of the most widely used ORMs in the world. Now, they’ve launched Prisma Postgres, and CEO Søren Bramer Schmidt is here to break down the journey, the challenges, and the massive technical innovations behind it—including bare-metal servers, Firecracker microVMs, and unikernels. If you care about databases, performance, or scaling, this one’s for you.

Want to learn more Postgres? Check out my Postgres course: https://masteringpostgres.com.

Follow Søren:
Twitter: https://twitter.com/sorenbs
GitHub: https://github.com/prisma/prisma
Prisma Postgres: https://www.prisma.io/postgres

Follow Aaron:
Twitter:  https://twitter.com/aarondfrancis 
LinkedIn: https://www.linkedin.com/in/aarondfrancis
Website: https://aaronfrancis.com - find articles, podcasts, courses, and more.

Database school on YouTube: https://www.youtube.com/playlist?list=PLI72dgeNJtzqElnNB6sQoAn2R-F3Vqm15
Database school audio only: https://databaseschool.transistor.fm 

Chapters:
00:00 - Introduction
01:15 - The Origins of Prisma: From GraphQL to ORM
02:55 - Why Firebase & Parse Inspired Prisma
04:04 - The Pivot: From GraphQL to Prisma ORM
06:00 - Why They Abandoned Backend-as-a-Service
08:07 - The Open Source Business Model Debate
10:15 - The Challenges of Monetizing an ORM
12:42 - Building Prisma Accelerate & Pulse
14:55 - How Prisma Accelerate Optimizes Database Access
17:00 - Real-Time Database Updates with Prisma Pulse
20:03 - How Prisma Pulse Handles Change Data Capture (CDC)
23:15 - Users Wanted a Hosted Database (Even When Prisma Didn’t)
25:40 - Why Prisma Finally Launched Prisma Postgres
27:32 - Unikernels, Firecracker MicroVMs & Running Millions of Databases
31:10 - Bare Metal Servers vs. AWS: The Controversial Choice
34:40 - How Prisma Routes Queries for Low Latency
38:02 - Scaling, Cost Efficiency & Performance Benefits
42:10 - The Prisma Postgres Roadmap & Future Features
45:30 - Why Prisma is Competing with AWS & The Big Cloud Players
48:05 - Final Thoughts & Where to Learn More