Postgres, Lisp, and Time Travel: Things we learned when some of the original Postgres team walked into our talk
How the architects of Postgres envisioned the self-driving database that we are building today with automated PostgreSQL tuning.
At DBtune, our daily mission is to solve one of the most notoriously complex "black boxes" in computer science: database tuning and performance optimization, a space where we pioneer the use of AI and ML. Recently, our team connected with some of the original architects who helped lay the foundations of PostgreSQL.
This article, based on conversations at the New York PostgreSQL conference, at a coffee shop in Mountain View, and some follow-up conversations, shows that many of the performance and tuning topics we work on today were already being discussed over 40 years ago. As modern engineering teams seek automated PostgreSQL tuning solutions to bypass manual overhead, looking back at the database's history reveals why AI-driven database optimization is the logical next step.
The serendipitous encounter: From PGConf to Mountain View
The connection began at PGConf NYC 2025. Luigi Nardi, DBtune CEO, attended a presentation given by Grant McAlister (Amazon RDS) focused on the persistent headaches of manual database tuning. During the session, an audience member raised his hand and asked a poignant question: "I've been tuning this system for decades. Can you just give me something that does it for me?" That audience member was Dr. Curt Kolovson, one of the original members of Michael Stonebraker's team.
Luigi, recognizing a shared obsession with the limits of manual configuration tuning, introduced himself after the session. That meeting led to a face-to-face conversation in Mountain View, where Curt brought along his friend Greg Kemnitz, also a member of the Postgres team at Berkeley 40 years ago. Postgres (without the SQL bit at the end) was the project that laid the foundations for what became PostgreSQL. At the meeting and during several follow-up calls, we discussed how DBtune's focus relates to the original work that Curt and Greg pursued in Michael Stonebraker's lab.
While the broader PostgreSQL community frequently celebrates 1996 as the project's inception, the actual engineering foundation was laid a full decade earlier by a small team at Berkeley. Curt and Greg were in the room when the very first concepts of "Post-Ingres" took shape.
At DBtune, we spend our days using agentic AI to optimize database performance, establishing ourselves among the next generation of PostgreSQL performance tuning tools. To understand where we're going and why things are the way they are, we wanted to understand more of the project's origins. We sat down with Curt Kolovson (implementer of the first Vacuum Cleaner Process) and Greg Kemnitz (the Chief Programmer of the Postgres Project who stabilized the Berkeley code) to perform some "database archaeology."
Celebrating the architects: Who are Curt and Greg?
Greg Kemnitz: The software engineer
In the late 1980s, university research teams rarely employed dedicated, industry-hardened software engineers. Academic code was notoriously transient; graduate students would write thousands of lines to power a thesis paper and then immediately move on, leaving behind fragile prototypes.
Greg Kemnitz: "Research software testbeds tend to be approached very differently from commercial development. There wasn't a grand overarching vision or standardization among the graduate students; the priority was simply for the code to compile and 'sort of work'. We didn't have system administrators: we did most of the ad-hoc heavy lifting ourselves."
Recognizing this gap, Professor Stonebraker brought Greg in from industry to serve as the project's stabilizing force. Greg performed a "necessary code triage," manually modernizing functions and discarding unmaintainable layers to shrink the experimental codebase from a bloated 220,000 lines down to a stable 170,000 lines. His work was the bridge that made Postgres usable for the outside world.
Curt Kolovson: The first implementer of Vacuum
As a PhD student at the Berkeley lab, Curt was given a challenging assignment: solving the storage logistics for Stonebraker's radical "no-overwrite" architecture that would allow users to travel back in time and run queries based on earlier points in time.
Curt Kolovson: "Stonebraker insisted that software developed in academia couldn't just be theoretical garbage—it had to work, be useful, and be practical. My job was to figure out how to manage a database that promised 'time travel' by never deleting historical data."
To prevent the physical disks of the 1980s from filling up, Curt authored the very first Vacuum daemon. While modern PostgreSQL DBAs know Vacuum as an automated garbage collector for Multi-Version Concurrency Control (MVCC), Curt's original code was built for a completely different economic reality: migrating old data chunks from magnetic hard drives onto optical storage media.
The bridge to the autonomous future
Speaking with Curt and Greg highlights an undeniable truth: the problem of tuning a database is as old as the Berkeley hills. In the 1980s, Greg had to triage student code to eke out stability and performance manually. In the decades that followed, engineers were forced to manually turn hundreds of obscure internal configuration knobs to handle changing workloads. Many of their default values were originally set based on the limits of 1980s hardware.
Today, PostgreSQL is the boring, reliable database of choice. But in 1986, it was a radical, "no-overwrite" research project that nearly collapsed under the weight of its own ambition. From Lisp-based parsers to 500MB hard drives that required two people to carry, the origins of PostgreSQL look nothing like the cloud-native giant we know today.
1. Lisp and the turtle
Q: Most developers assume PostgreSQL was always a sleek C-based engine. Why did it start as a Lisp machine?
Greg Kemnitz: In the mid-80s, Lisp was the "hot" language for AI and research. The very first version had the parser and optimizer written in Lisp because it was academically trendy.
Curt Kolovson: The early implementation of Postgres did suffer from some performance issues. As it turns out, the original mascot of Postgres was a turtle, mainly inspired by an old phrase, "turtles all the way down". Later, the turtle mascot was dropped, and the open-source community adopted an elephant as the PostgreSQL logo. Not sure why slow animals have long been associated with PostgreSQL, but it obviously wasn't the result of a well-thought-out marketing campaign.
Greg Kemnitz: We spent a year "delispifying" the front end. It was a massive technical debt. One of the greatest lessons from Berkeley was a "negative result": don't write a database engine in Lisp. It needs C to talk to disks. We eventually shrank the code from 220,000 lines to 170,000 just by throwing away the over-engineered student code.
2. The terrors of triage: Cutting 30% of the code
Q: Greg, you were tasked with turning a "research project" into something that actually worked. How did you handle the "student code" problem?
Greg Kemnitz: Grad students would come in, write 20,000 lines of code to get their PhD, and then leave. It was a mess of "organizational scars." My job was triage. I looked at the codebase and realized about 30% of it was either redundant or broken. I got much of the code to be consistent, but had to throw some code away.
Curt Kolovson: It was a necessary "bloodletting." By making the database smaller, Greg actually made it 10x more stable. It's a lesson in software engineering that still holds true: more code is rarely the answer to better performance.
3. Hardware horrors: The 500MB giant
Q: Today, we talk about petabytes in the cloud. What did "big data" look like in your lab?
Greg Kemnitz: I remember that day clearly: Wei Hong and I had to install a "massive" new hard drive. It was 500 megabytes. At the time, it was a physical ordeal. It was a huge, heavy rack-mounted unit. We had to lug it into the server room, sweating and worrying we'd drop a piece of hardware that cost more than our annual salaries. Managing "state" back then was a physical burden, not just a logical one.
4. The Vacuum origin story: It wasn't for garbage collection
Q: Curt, you wrote the very first Vacuum daemon. Modern PostgreSQL DBAs spend half their lives tuning it. Was that the plan?
Curt Kolovson: Not at all. In the '80s, we had a "no-overwrite" storage model. We thought people would want "time travel"—to see what the database looked like last Tuesday. Because we never deleted anything, the disk would fill up. My "Vacuum" was designed to migrate old data from magnetic disks to WORM (Write Once Read Many) optical drives. It was a data-migration tool for physical storage tiers. Today, it's a garbage collector for MVCC. The modern function only shares the name with my original work.
5. Marketing vs. science: The "object" pivot
Q: You've mentioned that "Object-Relational" was actually a marketing pivot. What happened?
Greg Kemnitz: It was a funding war. Professor Mike Stonebraker saw the University of Wisconsin getting massive grants for "Object-Oriented" databases. He walked into the lab one day and told the team: "Extended Relational is now Object-Relational."
6. The Ferrari vs. the truck (PostgreSQL vs. MySQL)
Greg Kemnitz: This is my favorite analogy.
- PostgreSQL is the Ferrari engine: It has the best "brain"—the query optimizer. It can handle 20-way joins and complex analysis that would break other systems.
- MySQL is the truck body: It has a better "body"—the storage engine and replication. It handles 10,000 simple connections easily.
- Greg's dream: My dream was to put the PostgreSQL "Ferrari" engine inside the MySQL "truck" body.
The next era: From manual triage to AI autonomy
As we sat there reminiscing about 500MB drives and Lisp turtles, a common theme emerged: PostgreSQL has always been a "knob-turner's" database. Curt mentioned that he wishes the "broken" MVCC and Vacuum would just disappear into a self-driving system. In the 80s, Greg had to triage code to find performance. Today, DBAs still have to tune parameters manually when seeking better performance.
The transition from human-managed triage to a self-driving database configuration is no longer an academic dream—it is a production necessity. At DBtune, we are building that exact intelligent layer that Curt and Greg envisioned 40 years ago. We use machine learning to navigate the thousands of configuration permutations that no human can manage, finally answering the question asked by Curt in that crowded PGConf conference room.
Postgres survived because it was the most "complete" system of the 80s. It will thrive in the market because it is the most "adaptable" system—especially when paired with AI that can finally handle the "Ferrari engine" under the hood.