boringSQL
boringsql.com · Personal blog · on HN since 2025
boringSQL is a PostgreSQL-focused blog covering internals, query behavior, indexes, MVCC, vacuum and EXPLAIN output.
What HN saysHN commenters link it for its posts on instant database clones in Postgres 18 and interactive visualizers, such as HOT updates, to explain concepts.
19HN people shared it
5linked it in comments
44stories submitted
793story points
3 months agolast shared
2025people per year2026
Most-shared posts
- 1Instant database clones with PostgreSQL 184 people · 395 points · first shared 2025 · 154 comments on HN
- 2The Cost of PostgreSQL Arrays3 people · 5 points · first shared 2026 · discussion on HN
- 3PostgreSQL's MVCC is bad. So is everyone else's3 people · 5 points · first shared 2026 · discussion on HN
- 4Vacuum Is a Lie: About Your Indexes2 people · 94 points · first shared 2025 · 50 comments on HN
- 5Reading Buffer statistics in EXPLAIN output2 people · 3 points · first shared 2026 · discussion on HN
- 6Welcome to ORDER BY Jungle2 people · 3 points · first shared 2026 · discussion on HN
- 7Production query plans without production data2 people · 3 points · first shared 2026 · discussion on HN
- 8Good CTE Bad CTE2 people · 3 points · first shared 2026 · discussion on HN
- 9PostgreSQL's 8KB Page2 people · 3 points · first shared 2026 · discussion on HN
- 10Beyond Start and End: PostgreSQL Range Types2 people · 2 points · first shared 2025 · discussion on HN
- 11RegreSQL: Regression Testing for PostgreSQL Queries1 people · 151 points · first shared 2025 · 38 comments on HN
- 12PostgreSQL Maintenance Without Superuser1 people · 80 points · first shared 2025 · 5 comments on HN
- 13PostgreSQL MVCC, Byte by Byte1 people · 6 points · first shared 2026 · discussion on HN
- 14The DISTINCT in Your COUNT1 people · 5 points · first shared 2026 · discussion on HN
- 15The curious case of Google's AlloyDB1 people · 4 points · first shared 2026 · discussion on HN
What HN people wrote when they linked it
stephen · 2026-08-01
I haven't had time to try it, but I thought running PG on a copy-on-write filesystem with a specific "clone template" incantation would get you instant clones? Probably doable in a docker container?
https://boringsql.com/posts/instant-database-clones/
eugercek · 2026-05-13
If you use xfs (+`file_copy_method=CLONE`) you can do this with Postgres 18.
`CREATE DATABASE clankerdb TEMPLATE sourcedb STRATEGY=FILE_COPY;`.
But Ardent can be useful for many, because cloud providers uses heavily restricted Postgres. And many use Aurora, which doesn't event let configure the `long_line_prefix`.
Though if cloud providers add file_copy_method=CLONE compatible managed pg ...
ref: https://boringsql.com/posts/instant-database-clones/
radimm · 2026-04-30
Somehow it feel HOT updates are very confusing. You can also try to play with interactive visualizer to understand it better https://boringsql.com/visualizers/hot-updates/
tee-es-gee · 2026-04-20
> You don’t need anything but vanilla pg and a supported file system to do it anymore; just clone the database using a template and a newish version of Postgres.
Are you referring to `file_copy_method = clone` from Postgres 18? For example: https://boringsql.com/posts/instant-database-clones/
I think the key limitation is:
> The source database can't have any active connections during cloning. This is a PostgreSQL limitation, not a filesystem one.
christophilus · 2025-12-23
I think the examples here are pretty good: https://boringsql.com/posts/beyond-start-end-columns/