Pinned
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.
Get 1% better today (at databases)
December 15, 2025 at 4:34 PM
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?
If we had to throw these databases away and begin from scratch in 2025, what would change and what would remain?
December 14, 2025 at 1:35 PM
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?
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)
Parting thoughts (in thread)
December 12, 2025 at 10:08 PM
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)
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.
- 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.
December 11, 2025 at 2:19 PM
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.
- 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?
When databases, message queues, connection poolers, or other systems get overloaded, how do they deal with the pressure?
December 10, 2025 at 3:56 PM
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?
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?
December 9, 2025 at 3:07 PM
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.
Still figuring out how to top this in 2026.
Taking ideas.
December 8, 2025 at 2:26 PM
IO Devices and Latency is the most ambitious article I've written.
Still figuring out how to top this in 2026.
Taking ideas.
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!
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!
December 7, 2025 at 1:35 PM
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!
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...
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...
December 4, 2025 at 6:43 PM
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...
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
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
Careers — PlanetScale
Building the database of the future, together.
planetscale.com
December 3, 2025 at 7:51 PM
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
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.
Running an app at scale demands a deeper understanding of indexing, joins, and data access patterns.
December 1, 2025 at 2:09 PM
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.
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.
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.
November 30, 2025 at 2:24 PM
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.
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-...
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-...
November 28, 2025 at 2:31 PM
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-...
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.
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.
November 26, 2025 at 5:10 PM
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.
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.
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.
This works via a combination of backup-restores and WAL replay.
November 24, 2025 at 3:46 PM
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.
This works via a combination of backup-restores and WAL replay.