Software at scale reveals the cracks. Managing a system for a single use-case (databases or otherwise) can make it seem like a perfect solution. It just might be for that narrow environment! At scale you see all the edge cases because you're operating on so many workloads.

What do Git, Cursor, and Dynamo have in common? Merkle trees! A great data structure for tracking file changes, facilitating incremental sync with remote servers. Say we want to track changes to a codebase at a per-file level. We compute a hash for each source file, and these become leaf nodes.

Need a break from AI in the timeline? Listen to me talk about data organization instead :) Friday's stream was a fun one. Sequential writes, binary search trees, block I/O devices, and B-trees. The latest slice dropped this afternoon. www.youtube.com/watch?v=84b_...

If 2026 is the year of AI, it's also the year to read more papers. LLMs make writing code cheaper. This places greater emphasis on architectural choices, understanding design tradeoffs, ensuring security, and building things people actually need. Great example: yesterday I read the Dynamo paper.

2026 is the year to end TikTok brain. Instead, learn database internals on YouTube. Speaking of which, another dropped today (link below).

Cameras, lenses, framing, and everything in-between have fascinated me for many year. This morning I read Bartosz Ciechanowski's article on the subject. It's the best explainer I've seen. The interactivity really sells it. Great article to kick off your year with: ciechanow.ski/cameras-and-...

We need indexes to make databases fast. BUT there are some important time/space and read/write optimization tradeoffs to consider! Latest YT → fun overview of this aspect of databases. www.youtube.com/watch?v=cNw9...

This is the best article I've read on MVCC in MySQL. MySQL and Postgres use quite different engineering techniques are used to address the same problem. Undo log vs multiple tuple versions. Another great one by Jeremy Cole. blog.jcole.us/2014/04/16/t...

I’ve recently seen multiple, unrelated instances of people referencing Bf-trees. Good job, @benjdd.com.

Had a great first "Database Internals" livestream yesterday. I'm aiming for more "regular" YouTubing in 2026, much of which will be chopping up interesting segments from the streams. Speaking of which: new video has DROPPED! www.youtube.com/watch?v=wdJe...

Amazing how one simple idea can revolutionize an industry. Binary search trees were invented in 1960. It seems obvious today, but this was a fresh way of thinking about ordered data on computers.

pgcli and mycli are wonderful upgrades from the default psql / mysql database clients. Auto-completion, syntax highlighting, and just generally much better usability. If you're connecting to your DB from the terminal, get these asap.

UX and performance are tightly correlated. Don't treat them as distinct concerns. We've all used software that's slow and becomes a huge turnoff. Fast software makes for happy users. Or at least, avoids making them mad!

Goal: benchmark Postgres 8.0 - 18.0. That's 20 years of database performance! I haven't started beyond "planning with Claude," but I expect the hardest part to be building old versions from source. Much has changed in compilers + unix since 2005. Who's done this? Suggestions?

PSA to my Postgres people: use a connection pooler. Incredible article on when and why to use PgBouncer. Includes a great explanation of how increasing direct connections leads to more contention → degraded performance. (+ benchmarks too!)

Name a more beautiful abstraction than the Unix pipe.

Log structures are all over the place in databases, but did you know they are used in file systems too? This week I re-read the iconic LFS paper by Rosenblum / Ousterhout. The differences between I/O demands on a database vs a general-purpose FS are neat to study.

I present to you: the 8 LOC database. Who needs ACID, relational schema, foreign keys, B-tree indexes, log-based commits, MVCC, replication, and failovers? We've been overthinking the database. Keep it simple.

GIN indexes are a powerful tool in Postgres. They’re great for inverting the typical use case. Instead of mapping “the row with ID 2 contains ‘become a database expert’” you flip it to say “The word ‘database’ maps to the rows with IDs 1, 2, and 3 and ‘expert’ maps to the row with ID 2.”

Two biggest customers requests since launching Metal: - Smaller compute sizes at a lower price point - More local-NVMe storage size options Today we've delivered both. Happy databasing.

Get 1% better today (at databases)

Postgres, MySQL, SQLite and many others were invented in the 90s and 00s, the era of spinning disks. A local NVMe SSD has ~1000x improvement in both throughput and latency. If we had to throw these databases away and begin from scratch in 2025, what would change and what would remain?

4 months later, DDIA complete. All 12 chapters. Wonder how many people who post about this book have read the whole thing? Parting thoughts (in thread)

Being knee-deep in Postgres, things I miss from MySQL: - B-tree table storage - Vitess - Undo log based MVCC - SHOW TABLES - Vitess - Buffer that doesn't rely on OS page cache - SHOW CREATE DATABASE But mostly, Vitess.

Backpressure is key for well-behaved infrastructure. When databases, message queues, connection poolers, or other systems get overloaded, how do they deal with the pressure?

Who's ready to build Sonnet 5.0 together?

IO Devices and Latency is the most ambitious article I've written. Still figuring out how to top this in 2026. Taking ideas.

Postgres has a process-per-connection architecture. Therefore, you should use a connection pooler whenever possible. These sit between the app and database. They maintain a pool of connections and dynamically map incoming requests to to them. PgBouncer is the most popular tool for this job!

Speaking of MySQL powering the internet - Uber runs on over 2,600 MySQL clusters! They recently moved many of these from a "traditional" primary-replica model to Paxos-based group replication. Great benchmarks included on their blog too. www.uber.com/blog/improvi...

Come work with me at PlanetScale! We're growing the team that educates and supports our engineering community. If you love databases and seeing customers succeed, these roles are for you. Specifically, we're hiring a Community Engineer and Developer Events Lead. planetscale.com/careers

ORMs are great, but you still need to learn SQL + database performance fundamentals. Running an app at scale demands a deeper understanding of indexing, joins, and data access patterns.

Think databases are boring? Indexing → data structures + algorithms AI → RAG + learned indexes MVCC → concurrent programming Sharding → distributed systems Query parsing → formal languages Query planning → stats + optimization Databases encompass tons of interesting software engineering problems.

Every now and then I stumble across an underrated article. An example: "Measuring Latencies Between AWS Availability Zones" (link below). An incredible resource for anyone building on AWS. What are your favorite, lesser-known blogs? www.bitsand.cloud/posts/cross-...

On a managed database, YOU benefit from the shared experience of the entire fleet. There's tons of hard-to-predict issues. Intermittent AWS network lag. PG + MySQL edge cases. etc. PlanetScale continually hardens our systems against these problems, and all customers win.

Databases 🤝 Physics

Postgres supports point-in-time recovery: the ability to "travel back in time" to a previous database state. This works via a combination of backup-restores and WAL replay.

These graphs never get old. Depot uses one of my favorite tools, PlanetScale Insights, to drill in on query performance issues and address them via schema change DRs.

Bf-trees are a high-performance alternative to the classic B-tree. The key contribution: Decoupling the size of on-disk pages from the size of memory cache entries. I'm curious if/when MySQL and Postgres will adopt modern versions of classic indexes.

Postgres databases now come with LLM-powered index recommendations. Indexes are crucial for database performance, and these recommendations help ensure your queries are executing optimally. Read about how we built this: planetscale.com/blog/postgre...

Intercom is powered by nearly 1000 MySQL instances. Sharding brought to you by Vitess. Amazing talk by Eugene Kenny at SF Ruby conf.

What are your favorite technical papers? I want to do some livestreams going over papers as a group. Much like my grad-school days of sitting in a classroom and discussing design tradeoffs of popular tech literature.

Postgres uses TOAST to store large, variable-sized data values like JSONB and TEXT. Using it impacts performance, so you gotta know the tradeoffs.

Don't be alarmed, I won't be blogging daily, but I did just publish a second article in as many days. Everything is lock-in rcrowley.org/2025/everyth...

S3 is powered by millions of HDDs. This Andy Warfield article is a fascinating look under the covers one of the largest storage systems on earth. I particularly enjoyed the discussion of scaling both the technology and ones self as an engineer. www.allthingsdistributed.com/2023/07/buil...

Biggest takeaway from KubeCon: People want Neki badly. We're building the solution for scaling and managing huge Postgres databases. More to come, but in the meantime: neki.dev

PlanetScale Insights is amazing. Correlating schema/config changes and performance has never been easier. The perfect tool for squeezing every ounce of performance out of your database resources.

Postgres handles MVCC with per-row transaction ID metadata. Every row (tuple) you insert into a Postgres table includes xmin and xmax metadata. xmin is the transaction that created the row, and xmax the one that updates or deleted it.

Not all CPUs are created equal. This latency graph shows a r6id → i7i upgrade. Same vCPU count. Same amount of RAM. Both using local SSDs. Upgrading to a newer instance makes a big difference.

The database community needs better benchmarks. TPCC is widely used for OLTP, but was published in 1992. Who's working on this? What do you want to see in a modern OLTP benchmark?

What happens when you INSERT a row in Postgres? Postgres needs to ensure that data is durable while maintaining good write performance + crash recovery ability. The key is in the Write-Ahead Log (WAL).