Weekly Video Notes — Classic of the Week. A foundational talk revisited, with source video and key frames embedded throughout.
Most Turing Award lectures are a victory lap through the technical contribution. Stonebraker refuses. He shows up without the tie the videographer asked for (“that just isn’t me”), announces that the audience isn’t a database crowd so he’ll have to teach them some database first, and then delivers 75 minutes braiding two stories together: the design and near-death of Postgres, and a tandem bicycle trip he and his wife rode across America.
The braid is the argument. If you want the technical talk, he tells you exactly where to find it — his Test of Time talk at ICDE that year. This one is about what it actually takes to get a research prototype into the world, and it is much more honest about the cost than the genre usually allows.
The setup: Codd, Ingres, and a pickup programmer
The context, for the non-database audience: in 1970 Ted Codd published his CACM paper arguing — completely contrary to the wisdom of the time — that all data should be stored in relations, the simplest possible structure, and that you should never write algorithms to find your data. You should just say what you want in a high-level language. That language is now SQL.
Two prototypes made Codd real in the 1970s: System R, built by roughly fifteen IBM PhDs, and Ingres, which Stonebraker notes he wrote “with a pickup programmer.” Both were aimed squarely at business data processing — beating IMS and CODASYL. It never occurred to them to worry about anything more general.
The research community promptly pointed out that these systems were brittle.
Postgres bet one: abstract data types
The brittleness showed up immediately in the geographic information systems work happening at Berkeley — points, lines, polygons, line groups. Stonebraker walks the audience through the simplest possible GIS query: you want a zoning variance, so you must notify every property owner within a certain distance. Take your lot, expand the rectangle, find every nearby parcel whose rectangle overlaps it.
He renders it in what he cheerfully calls “bastardized SQL” (his wife wouldn’t let him put real syntax on a slide). It works. It takes a minute of staring to convince yourself it’s correct. And it’s very difficult to optimize.
The diagnosis: Ingres and System R had a fixed set of basic data types and that was it. GIS doesn’t fit in integers and floats. What you actually want is boxes, polygons, points — and operators over them. Hence Postgres’s first bet: user-defined abstract data types, with user-defined operators, indexable and optimizable by the engine.
The best illustration comes from Wall Street. A trader complained that Ingres had just implemented date and time to the ANSI standard, which meant March 15th minus February 15th was 28 days — except in leap years, except in double leap years. He didn’t want that. If you own a bond, you get the same interest every month regardless of length; the answer he wanted was 30 days, and he wanted to overload subtraction rather than copy objects out to user code.
“Well, you could in Postgres. That was the whole idea.”
Postgres bet two: no-overwrite storage and time travel
The second bet targeted crash recovery. In Ingres and System R you don’t have one database, you have two: the data (drawn as a cylinder) and the log — with different access patterns, different engines, and a synchronization requirement between them.
The whole point is recovering from crashes: back out partially-completed transactions, guarantee the log was written first. And it has to be ultra reliable, because Murphy’s Law says it fails on your most important customer with their biggest problem, and then you’re on the front page of the Wall Street Journal. Log code is, in his words, ugly, complicated, and extremely hard to test — you can’t ask a machine to please crash right now so you can exercise the recovery path.
“I said, I don’t want to do this again. It’s too yucky.”
Hence no-overwrite storage: keep old versions instead of a separate log, and get time travel as a side effect. His verdict decades later is refreshingly unvarnished — time travel has a lot of promise but is very tricky to tune, and anyone who’s worked on log-structured file systems knows exactly why.
The third bet, an ALWAYS command for rule-based integrity, fared worse. He’d set the objective of handling all six cases of Chris Date’s referential integrity, couldn’t figure out how, and the entire implementation went over the cliff. Plan B.
The slog through the swamp
Here the bicycle metaphor earns its keep. The talk’s structural joke is that every technical low point is intercut with a photograph from the ride, and every genuine high point on the bike — cresting Marias Pass in Montana with the Cascades and Rockies finally behind them, “it is now downhill to Chicago” — arrives right when the research is at its worst.
Four years of tuning time travel, wrestling with complex objects, etc., etc., etc. And the parallel: North Dakota, which he assures the audience repeatedly is bleak beyond belief and not much fun to ride across.
Why it had to be a startup
The commercialization thesis is the most quotable part, and it’s grounded in Clayton Christensen’s The Innovator’s Dilemma, which he recommends everyone read. If you’re selling obsolete technology and new stuff comes along, you cannot move your customer base across without losing it. Therefore big companies are structurally uninterested in disruptive ideas like Postgres. Therefore technology transfer is best done through a startup.
So they founded one — eventually named Illustra — converting Postgres’s query language from QUEL to “the now intergalactic standard SQL,” hardening the code, improving performance. Honeymoon phase. First customers. Real management team.
Then the chicken-and-egg trap that nearly killed it:
They pitched application vendors: integrate with database search, get crash recovery for free, just convert your code to run as ADTs. The vendors asked how many customers Illustra had. Twenty. Come back when you have a thousand. They saw Illustra as a distribution channel, not a revolution — and customers wouldn’t come without the ADTs the vendors wouldn’t build.
Running out of money produced the down round, and Stonebraker explains the mechanics with unusual candour. Normally each round sells stock at a higher valuation. A down round doesn’t just dilute — most financing agreements reprice previous rounds down to the new price, so it’s doubly dilutive. Employees are not stupid: “why should I work for this startup if you’re going to dilute me off the face of the earth?” What follows is a three-way zero-sum negotiation between the existing investors (“the land sharks”), the new investor, and the employees.
The talk’s title comes from exactly this moment: Stonebraker at his brother’s fishing cabin, Illustra down to fumes, the land sharks on the squawk box.
They were eventually acquired by Informix, integrated successfully, and the product still shipped from IBM after it bought Informix in the early 2000s.
Make it happen
The payoff is deliberately anticlimactic. Why bore a Turing audience with a bike story? First, he says, to prove he can write an algorithm:
Until you reach the Atlantic Ocean: get up in the morning, ride east, overcome whatever comes up, and persevere across North Dakota.
Then apply a bit of abstraction — replace “Atlantic Ocean” with your goal, replace “ride east” with whatever action is appropriate — and make it a macro called make it happen.
His closing advice: don’t try to build a novel database system unless you have a lot of make it happen. Where does it come from? He declines to psychologize — “the simple way to duck is to say I don’t know.”
And then the counterweight, which is the part people usually leave out of these speeches: serendipity. Serendipity got them out of North Dakota — his brother showing up at the right moment, the wind doing what it did, none of it planned. It was pure serendipity that made Illustra successful. He believes the relational model itself had an enormous amount of serendipity behind it. He’s also been on the receiving end of bad luck, which will kill a startup dead when one of the elephants decides to trample you.
He closes by leaving the credits slide up long enough to read: the students who wrote the original Postgres under him and Larry Rowe — Joey Hellerstein and Marti Hearst now professors at Berkeley, Mike Olson chairman of Cloudera, Marcel Kornacker chief technologist of Impala. And an explicit debt to the systems programmers who turn rickety academic prototypes into rock-solid commercial code, because a database can never show the green screen of death.
The forward-looking coda holds up well: one-size-fits-all is legacy code that “deserves to be sent to the home for tired software,” replaced by vertical-specific engines — column stores for warehousing, main-memory lightweight transaction systems, array engines for complex analytics. He built one of each.
Key takeaways
- Postgres’s core bet was extensibility: user-defined abstract data types and operators, because fixed type systems can’t express GIS, finance, or anything else real.
- No-overwrite storage was a reaction to log code being “too yucky” — ultra-critical, ugly, and nearly impossible to test. Time travel came free, but tuning it never got easy.
- Not every bet lands. The
ALWAYSrule system died on Chris Date’s six referential integrity cases and was thrown away entirely. - Disruptive technology can’t ship from an incumbent. The Innovator’s Dilemma is why tech transfer runs through startups.
- The chicken-and-egg chasm is a real failure mode: partners want your customers, customers want your partners, and no amount of technical merit breaks the loop.
- Down rounds are doubly dilutive because prior rounds get repriced — and the resulting employee renegotiation is where startups actually die.
- “Make it happen”: get up, act toward the goal, overcome what comes, persevere across North Dakota. He offers no deeper theory than that.
- Serendipity deserves equal billing with perseverance. Stonebraker credits luck for Illustra’s survival and for the relational model’s rise — a rare admission in a lifetime-achievement talk.
Source
- Talk: Michael Stonebraker 2014 ACM A.M. Turing Award Lecture — “The Land Sharks Are on the Squawk Box”
- Speaker: Michael Stonebraker (MIT)
- Origin: Association for Computing Machinery (ACM)
- Duration: 1h 15m 49s
- URL: https://www.youtube.com/watch?v=BbGeKi6T6QI