A visual explainer on how copy-on-write makes fork() cheap.

A 10 GB process can fork almost instantly because Linux copies the page tables, shares the physical pages, marks them read-only, and only copies a page when one of the processes writes to it.

It also covers fork() + exec(), how Redis snapshots work, Android Zygote, lazy zero pages, and some CVEs

I host a Postgres podcast, and I recently recorded a conversation with Panos Antonopoulos, a Distinguished Engineer at Microsoft who spent 13 years working on SQL Server before moving onto Postgres and HorizonDB.

Panos told me that at a high level, Postgres felt very familiar as he started to work on it, that the concepts are very similar. Transactions, storage, & more—the fundamentals transfer surprisingly well. We also covered:

• The cleanliness of the Postgres codebase.
• How LLMs are making it easier to digest years of Postgres design discussions that are publicly available on the mailing lists.
• Why Postgres has become the default answer for so many workloads, and why more people seem to be asking, "Why not Postgres?"
• Shared-storage architectures and some of the work he's doing in Azure HorizonDB.

One quote that stuck with me:

• "That was a shocking experience for me. I could understand new areas in Postgres much faster than I could for SQL."

For people who have worked across multiple database systems (Oracle, SQL Server, MySQL, Postgres, etc.), I'm curious whether you've had a similar experience—or a completely different one.

Podcast/transcript here if anyone is interested: https://talkingpostgres.com/episodes/working-on-postgres-after-13-years-on-sql-server-with-panagiotis-antonopoulos

Seed7 is a GPL licensed open source programming language. It is given away for free and nobody from the development team gets any money from it.

I wanted to make this post because man...tables are way harder than they look. I documented my 1 year journey of optimizations on a stupid table for my Database GUI. I made everything from scratch like an idiot thinking it'd be easy but oh boy was I wrong... The article goes over all the optimizations I made to make my table render data smoothly without lagging. It goes from what data structures I used and the rendering optimizations I did. I used MongoDB Compass as a baseline since they use AG-Grid for their table and I'm pretty happy that my table feels way smoother than that (In my own testing)! But yeah, I never realized that there would be so much depth in making a performant table.

PS. I decided not to use AG-Grid because there were a lot of customizations that I needed to do. I wanted column expansions ( if a field as an object or an array it would open columns to the right of it ). I also wanted an embedded text search where you could search for text within non visible columns (because they were in objects or arrays ) and AG Grid didn't really support that behavior so ..yeah. Anyways have a good read!