Database School

Try Hard Studios
  • 5.0(3개의 평가)
  • 과학 기술

Join database educator Aaron Francis as he gets schooled by database professionals.

  1. 8월 19일

    Sharding Postgres without extensions with PgDog founder, Lev Kokotov

    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/levpgdogPgDog: https://pgdog.dev Follow Aaron: Twitter: https://twitter.com/aarondfrancisLinkedIn: https://www.linkedin.com/in/aarondfrancisWebsite: https://aaronfrancis.com — find articles, podcasts, courses, and more.Database School: https://databaseschool.com Chapters 00:00 - Intro01:27 - Lev’s self-taught to computer science degree journey04:50 - Transition to Postgres discussion05:24 - History of PgCat07:06 - What PG Cat does and key features08:59 - Why Lev built PgCat instead of extending PG Bouncer10:06 - PG Cat’s current status and usage12:20 - Moving from PgCat to PgDog13:09 - Applying to YC as a solo founder16:24 - YC pitch: the market gap for Postgres sharding18:52 - High-level overview of PgDog23:32 - Why PgDog is not an extension25:57 - When to build Postgres extensions vs standalone tools27:49 - PgDog architecture and query parsing30:39 - Handling cross-shard queries and current capabilities33:47 - How PgDog shards an existing large Postgres database36:37 - Parallel replication streams for faster sharding39:07 - Alternate resharding approaches42:52 - Where PgDog draws the orchestration line44:00 - Vision for PgDog Cloud vs bring-your-own-database46:47 - Company status: first hire, design partners, and production use50:45 - How deploys work for customers52:20 - Importance of building closely with design partners54:05 - Paid design partnerships and initial deployments56:23 - Benefit of sitting outside Postgres for compatibility58:32 - Near-term roadmap and long-term vision1:01:03 - Where to find Lev online

    49분

  2. 8월 8일

    Rewriting SQLite from scratch (yes, really)

    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

    1시간 18분

  3. 7월 1일

    Vitess for Postgres, with the co-founder of PlanetScale

    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

    1시간 7분

  4. 6월 27일

    PlanetScale Metal

    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.comPlanetScale: https://planetscale.comPlanetScale Metal: https://planetscale.com/blog/announcing-metal Follow Richard: Twitter: https://twitter.com/rcrowleyWebsite: https://rcrowley.org Follow Aaron: Twitter: https://twitter.com/aarondfrancisLinkedIn: https://www.linkedin.com/in/aarondfrancisWebsite: 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

    50분

  5. 5월 29일

    From Prisma Founder to LiveStore: Building local-first apps with Johannes Schickling

    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

    1시간 32분

  6. 5월 14일

    How Durable Objects and D1 Work: A Deep Dive with Cloudflare’s Josh Howard

    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-F3Vqm15Database 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

    1시간 15분

  7. 5월 6일

    20 years of hacking Postgres with Heikki Linnakangas (cofounder of Neon)

    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-F3Vqm15Database 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

    2시간

  8. 4월 18일

    Building a serverless database replica with Carl Sverre

    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-F3Vqm15Database 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

    1시간 29분
모두 보기(19개)

평가 및 리뷰

5
최고 5점
3개의 평가

소개

Join database educator Aaron Francis as he gets schooled by database professionals.

정보

  • 제작진
    Try Hard Studios
  • 방송 연도
    2024년 - 2025년
  • 에피소드
    19
  • 등급
    전체 연령 사용가
  • 저작권
    © 2025 Try Hard Studios
  • 웹사이트 보기
    Database School

좋아할 만한 다른 항목