Ben
@benjdd.com
databases @planetscale.com
Some stuff I've written:
- https://pscale.link/io
- https://pscale.link/btrees
- https://pscale.link/sharding
Find me at benjdd.com
Some stuff I've written:
- https://pscale.link/io
- https://pscale.link/btrees
- https://pscale.link/sharding
Find me at benjdd.com
Pinned
Reposted by Ben
Introducing pg_strict for Postgres.
Our new extension adds a safety net to Postgres, catching dangerous queries before they run.
www.youtube.com/watch?v=noPn...
Our new extension adds a safety net to Postgres, catching dangerous queries before they run.
www.youtube.com/watch?v=noPn...
Protect your database. Use the pg_strict Postgres extension.
YouTube video by PlanetScale
www.youtube.com
January 15, 2026 at 5:35 PM
Introducing pg_strict for Postgres.
Our new extension adds a safety net to Postgres, catching dangerous queries before they run.
www.youtube.com/watch?v=noPn...
Our new extension adds a safety net to Postgres, catching dangerous queries before they run.
www.youtube.com/watch?v=noPn...
If databases fascinate you like they do me, this article's for you!
Every time you interact with a website, database transactions are keeping your data consistent, safe, and isolated.
I wrote an interactive guide to how they work ⬇️
Every time you interact with a website, database transactions are keeping your data consistent, safe, and isolated.
I wrote an interactive guide to how they work ⬇️
January 14, 2026 at 7:41 PM
If databases fascinate you like they do me, this article's for you!
Every time you interact with a website, database transactions are keeping your data consistent, safe, and isolated.
I wrote an interactive guide to how they work ⬇️
Every time you interact with a website, database transactions are keeping your data consistent, safe, and isolated.
I wrote an interactive guide to how they work ⬇️
Tuning your database just right can be counter-intuitive, unless you understand all levels of the system.
Intuitively, most would say "more work_mem = better" for building indexes, but this hurts performance due to L3 cache behavior.
Great article by Tomas Vondra.
vondra.me/posts/dont-g...
Intuitively, most would say "more work_mem = better" for building indexes, but this hurts performance due to L3 cache behavior.
Great article by Tomas Vondra.
vondra.me/posts/dont-g...
January 13, 2026 at 2:10 PM
Tuning your database just right can be counter-intuitive, unless you understand all levels of the system.
Intuitively, most would say "more work_mem = better" for building indexes, but this hurts performance due to L3 cache behavior.
Great article by Tomas Vondra.
vondra.me/posts/dont-g...
Intuitively, most would say "more work_mem = better" for building indexes, but this hurts performance due to L3 cache behavior.
Great article by Tomas Vondra.
vondra.me/posts/dont-g...
R-trees are a powerful structure for indexing geometric data.
They’re used by MySQL, and Postgres uses an R-tree-like structure via GiST in PostGIS.
🧵
They’re used by MySQL, and Postgres uses an R-tree-like structure via GiST in PostGIS.
🧵
January 11, 2026 at 1:34 PM
R-trees are a powerful structure for indexing geometric data.
They’re used by MySQL, and Postgres uses an R-tree-like structure via GiST in PostGIS.
🧵
They’re used by MySQL, and Postgres uses an R-tree-like structure via GiST in PostGIS.
🧵
I'm excited about the database performance io_uring will unlock.
Last year I benchmarked Postgres 17 vs 18 to test the initial io_uring upgrades. I was surprised to see they weren't always a clear win for TPC-C.
This paper studies the potential, and the future looks good.
Last year I benchmarked Postgres 17 vs 18 to test the initial io_uring upgrades. I was surprised to see they weren't always a clear win for TPC-C.
This paper studies the potential, and the future looks good.
January 8, 2026 at 2:15 PM
I'm excited about the database performance io_uring will unlock.
Last year I benchmarked Postgres 17 vs 18 to test the initial io_uring upgrades. I was surprised to see they weren't always a clear win for TPC-C.
This paper studies the potential, and the future looks good.
Last year I benchmarked Postgres 17 vs 18 to test the initial io_uring upgrades. I was surprised to see they weren't always a clear win for TPC-C.
This paper studies the potential, and the future looks good.
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.
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.
January 6, 2026 at 1:37 PM
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.
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.
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.
January 5, 2026 at 2:37 PM
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.
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_...
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_...
January 4, 2026 at 10:41 PM
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_...
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.
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.
January 4, 2026 at 1:42 PM
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.
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).
Instead, learn database internals on YouTube.
Speaking of which, another dropped today (link below).
January 1, 2026 at 10:04 PM
2026 is the year to end TikTok brain.
Instead, learn database internals on YouTube.
Speaking of which, another dropped today (link below).
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-...
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-...
January 1, 2026 at 3:04 PM
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-...
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...
Latest YT → fun overview of this aspect of databases.
www.youtube.com/watch?v=cNw9...
December 31, 2025 at 8:52 PM
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...
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...
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...
December 31, 2025 at 4:34 PM
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...
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...
Reposted by Ben
I’ve recently seen multiple, unrelated instances of people referencing Bf-trees. Good job, @benjdd.com.
December 30, 2025 at 8:09 PM
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...
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...
OLTP vs OLAP and the row / column storage tradeoff
YouTube video by Benjamin Dicken
www.youtube.com
December 30, 2025 at 4:20 PM
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...
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.
Binary search trees were invented in 1960. It seems obvious today, but this was a fresh way of thinking about ordered data on computers.
December 30, 2025 at 2:14 PM
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.
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.
Auto-completion, syntax highlighting, and just generally much better usability.
If you're connecting to your DB from the terminal, get these asap.
December 29, 2025 at 2:40 PM
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.
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!
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!
December 26, 2025 at 2:08 PM
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!
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?
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?
December 24, 2025 at 2:17 PM
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?
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!)
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!)
December 22, 2025 at 2:16 PM
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!)
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.
December 21, 2025 at 9:29 PM
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.
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.
December 19, 2025 at 9:38 PM
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.
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.
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.
December 18, 2025 at 5:07 PM
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.
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.”
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.”
December 17, 2025 at 2:21 PM
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.”
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.
- Smaller compute sizes at a lower price point
- More local-NVMe storage size options
Today we've delivered both. Happy databasing.
December 15, 2025 at 4:54 PM
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.
- Smaller compute sizes at a lower price point
- More local-NVMe storage size options
Today we've delivered both. Happy databasing.