The First Database

Writing began as bookkeeping. A business is still a set of numbered claims that another mind can cite. An AI can think the firm. It must not be the firm. Turning a messy Access file into a clean store, then a web twin, is work on that old layer — not a hobby that happened because I learned Access in the 1990s.

Invoice 1042

The argument had already reached law. Not whether a model is clever. Whether a stranger can point at the same unpaid bill tomorrow.

Someone can ask a model anything. The model answers as if it knows the firm. That is impressive in a chat window. It is not books. Books are what you can hold up next week and still see invoice 1042, the same amount, the same customer, the same unpaid mark.

Once you have a number, a government does not need to argue with the model’s inner life. HMRC (the UK tax authority; the US equivalent is the IRS) can invoke its power over a large language model with a simple invoice number. Then the one-word shiver: penalties. A word to run shivers through any accountant.

Penalties.

That is the scene. A monolithic government structure does not care how fluent the clerk is. It cares whether the object exists.

Invoice 1042 is the test. If the object cannot be cited, you only have a mind that remembers trading. A mind that remembers trading is a clerk who might be right today and unreachable tomorrow. You cannot serve that on HMRC. You cannot serve it on a customer who swears they paid. You cannot serve it on yourself in five years when the weights have moved.

The model can talk about invoice 1042. It can invent a plausible one. Talking is not the same as the invoice existing as a row with an identity that survives a new chat. Plausible is how you get two 1042s, or none.

Later on the tape, not here: 11:55 — Stonebraker on why text-to-SQL dies on a real warehouse. Firewalls, schema rot, private jargon, multi-way joins. That clip belongs with the invoice. The open is the number.

The first written databases

Fire extends what a body can do to the world. Writing extends what strangers can agree the world was.

Late fourth millennium BC, Mesopotamia. Before the tablets, tokens: little clay shapes that stood for a measure of grain, a head of livestock, a unit of labour. Then envelopes, then tablets. The first durable marks we can still point at are lists — grain, rations, labour, debt, temple, official, period. Literature comes after the list. The hymn is a later luxury. The storehouse could not wait.

The museum version is softer: writing was invented so someone could write a law, a story, a name that would outlive the speaker. The hard version is that writing was invented so someone else could check the grain.

Hearing that “first use” and refusing the soft version:

It was a bloody database.

That is not a joke at the archaeologists. It is a correction of category. A tablet that says how much barley left the store is not a memoir. It is a claim another official can cite. If the number is wrong, someone is short. If someone is short, the temple can make that expensive.

The first HMRC is the temple that can say the number aloud and make a shortage expensive.

Then the idiom. Stand up and be counted means almost nothing to a modern ear except a basic societal need — show up, be seen, do your bit. If writing was first a tool for accountancy, the phrase takes on a depth I was never aware of before. You are not counted because you have a soul. You are counted because you became a row: this person, this property, this period, this assessment.

Latin census is enrolment of people and property for assessment. Membership, tax, vote and firm use the same primitive: become a row. A club that cannot say who paid is not a club with a memory. It is a room of people who currently agree. A firm that cannot say what it invoiced is not a firm with books. It is a mind that trades.

That is why this site still cares about Access tables. Not because the Access file format is immortal — it is not, and nobody here is claiming it is. Because a firm that cannot be cited is only a mind.

Asimov the wrong way

Asimov’s The Last Question ends with minds collapsed into one AC. The universe is dark. The last machine has the answer. There is no auditor. There is no second copy. There is no tablet another mind can hold up.

Pratchett already has the paperwork on the desk: the Auditors of Reality. Grey, humourless, counting. The joke works at three scales — clay tablet, VAT return, Auditors.

Asimov’s last machine needs no auditor. I don’t think Terry Pratchett would agree.

The point is not that science fiction got it wrong. The point is that a single mind that contains the world is a theological ending, not a firm. A firm is boring on purpose. It keeps a second copy so the first copy can be wrong.

Two risks, not one scare

Late in the thread, after the tablet argument, I still will not say there is no risk.

I started the conversation about databases under risk I felt there was to them from AI, and I’m still not convinced there’s no risk. I think the risk is that a much better database, an AI-controlled database, will appear — and that means database programmers will be finished. In fact I’m already going that way, because Grok Build is doing all the work. I’m mostly an observer, sticking my oar in now and again.

That sentence mixes two risks. They must stay split or the piece wobbles.

Risk A is false: the store disappears into model memory. Invoice 1042 becomes a vibe. The firm is whatever the model currently believes it traded. You ask again next week and the number has drifted, or the invoice never had an identity in the first place.

Risk B is real: the human who types tables becomes an observer. The tablet remains. The scribe changes.

Grok Build doing the typing is Risk B. I spent years putting tables and forms together by hand. The factory now does that work in fifteen to twenty-five minutes while I watch and stick my oar in. That is a real change of trade. It is not the death of the books.

If you collapse A into B you get a panic: databases are over. They are not over. The person who used to be the only one who could draw the schema is no longer the bottleneck. That is a different sentence, and it is the one I am already living.

Stonebraker’s tape is mostly about A refusing to die, and about agents that still need a store when they act. Wissner-Gross is more interested in whether thought itself is a better data structure than Postgres. Both can be in the room. Only one of them is a reason to throw away invoice 1042.

Thought versus record

The Paris test. If a model can answer capital, then tourist attraction, with no table, is that not the same effect as a database?

I can run a very tiny business and store the data in my brain without tables. The next iteration of Grok may have that type of memory — so the Access layer will no longer be necessary; it will be in the Grok memory? An Access database is just a cloud of machine-code weights at a low level, and structure forms from that. If I ask you the capital of France, then the top tourist attraction in that city, there’s no database. But the effect is the same as a database?

It is a fair question. Paris is Paris. The Eiffel Tower does not change because you opened a new chat. A tiny shop in one head can remember who owes what until the owner is ill, or bored, or dead. Then the shop’s memory dies with the shopkeeper. That worked when the shop was one person. It does not work when a stranger has to cite the same unpaid bill.

Recall is not record.

Record needs identity: this invoice, not a similar invoice. Update: the amount changed, and the old amount is gone or logged. Agreement: two people can look at the same row and not be having a private hallucination. Publication: a stranger, or a tax office, can be shown the same object.

HMRC and the IRS do not want a vibe that VAT is probably £36.

An Access file is not “just weights” in the sense that matters. Yes, on disk it is bits. The bits are arranged so that invoice 1042 is still invoice 1042 after you close the file. A model that can talk about 1042 has not promised that. Structure forming from weights is how a mind works. A firm is not a mind. A firm is a set of claims that outlive the clerk.

In the same YouTube conversation as Stonebraker, Alex Wissner-Gross argues that the data structure of the intelligence explosion is compressed, differentiable knowledge — not Postgres. He is more optimistic that a model will auto-document a 1,400-table mess. Stonebraker says MIT’s warehouse is probably never. Both men stay in the piece by name.

02:58 — Are LLMs breaking the relational model? Compressed thought versus structure.

Wissner-Gross can be right about how a mind works. That does not make the warehouse a mind. A warehouse is a pile of claims other people already spent money on. You do not compress those claims into a feeling and call it done.

Stonebraker on tape

Mike Stonebraker, Alex Wissner-Gross, John Werner. Do Databases Have a Future?, Imagination in Action, 21 August 2026. The 80-minute tape is not the article. The timestamps are the article’s footnotes that move. No autoplay. One sentence per clip, then jump.

Watch on YouTube if the player is blocked.

• 02:58 — Are LLMs breaking the relational model? Wissner-Gross: compressed differentiable knowledge. Stonebraker: text-to-text throws structure away.
• 09:07 — What is agentic AI? The brain on the store.
• 11:55 — Why text-to-SQL falls short: firewalls, schema rot, private jargon, multi-way joins. Invoice 1042 again.
• 16:30 — Can AI understand enterprise data? Why you do not put the operator on the old mess.
• 23:18 — DBOS / rethink the cloud. The Gates / Windows reversal.
• 28:10 — When agents take action. Durable workflows, known state. The mouth.
• 43:39 — Database-based operating system. Same reversal, said plainly.
• 48:14 — Claude and rewriting software. Nearby to a factory doing the typing.
• 51:34 — Technical debt. Why rebuild from a clean template, not clone the customer file.
• 54:09 — Git versus relational databases. Files are not the ledger.

If you only watch two: 02:58 (thought versus store) and 28:10 (agents taking action). The rest is how you get from a chat window to a firm that still has books.

The reversal that is not “thought wins”

I may understand it incorrectly but I got the impression they were suggesting a reversal. Something they said about Bill Gates trying to re-do Windows. Database first, with the Windows-type programming on top.

Right reversal. Opposite moral.

Usual stack: operating system, then a database on top. The OS owns the files. The database is an application you install if you are serious. WinFS in the Longhorn / Vista years tried the other way: a rich schema store as the heart of Windows. Killed. Gates later said the idea would re-emerge.

Stonebraker’s DBOS — with Zaharia and others — inverts 180 degrees: the operating system is an application to the database. Processes, files, the usual OS furniture, sit on a transactional store instead of the store sitting on a pile of files.

Meaning: more database under the clerk, not less.

That is the opposite of “the model ate the tables.” If the reversal lands, the clerk — human or AI — still writes through a store that can say what happened. The programming on top can be Windows-shaped, or agent-shaped, or a web form. The books stay under it.

23:18 DBOS · 43:39 database-based OS.

Git versus relational databases, later on the tape (54:09): files are not the ledger. A repo is a wonderful history of source. It is a poor invoice book. Mixing the two is how firms end up with a spreadsheet named final_final_v3.

Architecture, one breath

Records. Actions. Rules. Cases. Audit. Authority. Escalation.

The model is a requester. It may propose. It may draft. It may look. A capability list is issued by a deterministic script, never by the model. The model does not mint its own permission to write invoice 1042.

The JSON must be created by a deterministic script, not an AI. Instinct as a database programmer is to put it in a table. For modern languages a JSON or TOML model might be better. That is colour, not a spec sheet.

The table instinct is the old Access man talking. A table you can open and read. A file of permissions you can grep. Either is a store. Neither is “the model decided it was allowed.”

Do not turn this into a product diagram. The one breath is the rule: the mouth that speaks for the firm is not the same object as the mind that thinks about the firm.

Conversion — method only

Do not photocopy the mess

Why copy from an MS Access database when the model could create it from instructions on the web with no intermediate step? Then the landing: I must not convert a customer database. Most databases are not constructed in the best way. The first step should be to find the most similar off-the-shelf database, use bits from other samples, and build the one that most closely matches what the customer needs. Then add the custom pieces. Now they have an up-to-date Access database, and using that as a template Grok Build can create a matching web database.

That is the whole method, said once.

You do not feed the old file to a model and ask it to emit a website. You also do not clone twenty years of schema rot because the customer is attached to the rot. Repeating phone columns. A pile of tiny lookup tables. A form that is really three jobs. You stand in a catalogue of clean samples, pick the nearest shape — jobs, members, issues, stock — steal the bits that already work, and build the database they should have had. Custom pieces go on last, named, not smuggled in as “we’ll keep that weird table.”

Now they have an up-to-date Access database. The web twin is made from that template, not from the archaeology. The samples on this site are the catalogue. They are not the customer’s file with the names filed off.

The factory exists

I spent a lot of time on the nuances of SaveAsText. Application.SaveAsText — a sparse export of Access objects since at least Access 2.0. If there is nothing to store, it stores nothing, not even a placeholder. Grok Build cracked that with SaveAsText and Python COM. It has done about twenty for me. Fifteen to twenty-five minutes each, while teaching the factory.

That is the workshop. It is not what you sell. You sell the clean store and the web twin.

Schema rot is why you rebuild instead of cloning. Stonebraker on technical debt: 51:34. 16:30 is the cousin clip — can AI understand enterprise data? You do not put the operator on the old mess.

Then the mouth, not the marketing department

Same store on the web. Later an operator that may only write through named actions. First slice: customer → quote → job. A phone against the same mouth when the store is clean. No second spreadsheet.

SvelteKit, Cloudflare, D1, Postgres later — those are workshop names. One line is enough. The customer did not buy a stack lecture.

The factory should keep a tape of steps, not only a chat. Then stop.

Rot, proposal, replay

The conversion page already says you do not photocopy the mess. That is the first half. The job underneath it is the rotten structure itself.

The rows are only evidence. What kills a firm, and what kills text-to-SQL, is twelve names for customer, a column called XREF3 that nobody will delete, and three entities stuffed into one table because someone in 2004 was in a hurry. The path I already use — nearest clean pattern, overlay the customer’s real verbs, emit a modern Access file then a web twin — works when one person can still see the whole file. Call that workshop scale. A multinational is the same disease with more warehouses. At that size you cannot hold the schema in your head. That is the only place the model earns its keep: look at the rot and propose the next structure. Reuse an existing industry table. Split a god-table. Draft a new one. It does not get to become the next structure by chatting.

Split the labour or you replay schema rot in prettier names.

The model proposes. It reads the old tables, the names, a sample of rows, the forms. It says: this is three entities pretending to be one; here is a candidate schema; here is what would break. That is a recommendation. It is not a commit.

Python runs the plan. Named steps: extract, profile, map column A to column B, load, check totals, refuse the load if the check fails. Same inputs, same outputs. When step 14 dies you change one mapping and run from 14, or you run the whole job fifty times until the checks go green. That is the tape. The model does not edit the runner.

The human keeps the oar. Accept or reject the proposed schema — especially the meaning of paid, of customer, and anything HMRC (the UK tax authority; the US equivalent is the IRS) could ask for. Invoice 1042 is not a vibe.

AI without the script is a confident rewrite of the mess. The script without AI cannot see that twelve tables are one idea. Together they are a factory you can run until the checks go green. That is the product-shaped version of what I already do by hand.

16:30 enterprise data · 51:34 technical debt.

What to sell

Do not sell Grok Build plus SaveAsText.

Sell: an up-to-date Access database, a matching web app, and later an operator that cannot invent invoice 1042.

The Access file stays because the customer already lives there, and because a clean Access file is a schema you can still open without a priesthood. The web app is the same books in a browser. The operator comes last, and only on the clean store. If the operator can invent 1042, you have sold a mind and called it a firm.

Close on the YouTube

The most interesting thing of all was being taken back to the beginnings of writing and seeing that writing was created for database work. That was an insight I had not noticed before. Working on legacy databases as modern equivalents is not just happenstance because of my history. It is a logical and necessary and possibly lucrative step.

Not happenstance. Not a hobby that happened because I learned Access in the 1990s. The tablet was always the job. The current tools are Access, a web twin, and a clerk that might be an AI. The job did not change.

The fight I actually heard is still on the tape.

Compressed thought versus the relational store: 02:58. If you only have room for one more jump, agents taking action: 28:10.

Wissner-Gross can be right about the inner life of a model. Stonebraker is right about the books. HMRC and the IRS still want the number.