I’ve always seen databases as a black box that, somehow, stored data and retrieved it extremely fast. In college I learned that internally there was a “tree-like” structure, that allowed the database to efficiently lookup for data, but that’s as far as it went in the explanation. Our teacher (a very knowledgeable man that I admire) focused in making us learn procedures, triggers and correct data modeling. And so I went into my first job and did so: I designed an extremely well designed database, but still without understand how relational DB worked internally.

Soon I got my next job which involved a huge system, and myself (a junior) being the one in charge of designing the database and the backend services, thing got clear: I cannot keep treating databases as a SELECT * FROM table machine. I was afraid of messing up, afraid of triggering full table scans because I mis-optimzed something or unindexed queries.

I could feel the weight of the database on this system, and so I decided to learn deeply about internals. This series comes from a simple realization: I knew how to talk to PostgreSQL, but I had no idea what it was actually doing.

I am not writing this to become a DBA, a data analyst or an expert in data engineering. I don’t build BI dashboards, and I don’t pretend to be a researcher either. I am a backend and infrastructure developer which is afraid of messing up, but with something clear in mind: If you don’t understand how your database thinks, your backend will always be fragile. You cannot advance, you cannot redo (yeah, like in Evangelion 3.0+1.0).

Here, I want to learn in public, and explore the things that exist beneath basic CRUD: how B-Trees actually walk down disk pages, why the leftmost prefix rule matters, how the query planner estimates costs, what MVCC does behind the scenes, and how modern features—like PostgreSQL 18’s skip scans—change the rules.

This series is not a comprehensive database course, and it will never be even close to it. These are my notes while learning in public. Discovering what PostgreSQL can do when you stop treating it like a black box.