Daniel sent us this one — he's been thinking about the spreadsheet versus database question we've touched on before, and he's landed on something sharper. His argument is basically: if tools like Airtable and AI agents that write SQL are making database-backed systems nearly as easy to use as spreadsheets, what's left for the spreadsheet? Its only real advantage was usability. And if that's shrinking, maybe spreadsheets don't have independent value anymore. Maybe we should just centralize around SQL and be done with it. He's asking whether spreadsheets earn their place, or whether they're a legacy crutch we're all too comfortable to abandon.
That's a genuinely uncomfortable question for a lot of organizations. The spreadsheet is arguably the most successful software interface ever built. VisiCalc shipped in nineteen seventy-nine. That's over forty-five years of dominance. And I think Daniel's timing is sharp here, because something concrete happened this year that makes this more than a philosophical debate.
Airtable's SuperAgent.
January twenty-seventh, twenty twenty-six. Airtable announced this feature that lets users type natural-language questions and get AI-generated SQL queries executed against a relational database, all inside a grid interface that looks and feels like a spreadsheet. That collapses the usability gap in a way that's not theoretical anymore. It's shipping.
The question isn't "will databases catch up to spreadsheets on ease of use." They already have, at least in one major product. The question is whether spreadsheets have anything left to offer that isn't just familiarity and muscle memory.
That's what we should dig into. Not spreadsheets versus databases as a technology comparison — that's been done to death. But the specific claim Daniel's making: that the spreadsheet's last mile of convenience no longer justifies its costs, and that centralizing around SQL would actually streamline things across industries.
Let's unpack what spreadsheets actually give us that databases don't — and whether those advantages are real or illusory.
The starting point has to be the spreadsheet's killer feature, which is also its greatest liability. You can type anything anywhere. There's no schema. You open a blank grid, click into cell A1, and type whatever you want. A number, a date, a paragraph of text, an emoji, a half-baked formula you copied from Stack Overflow. The spreadsheet doesn't stop you.
Which feels like freedom.
It feels like freedom, and for the first five minutes it is freedom. But the technical term for what's happening here is schema-on-read versus schema-on-write. A database enforces structure when data goes in — schema-on-write. You declare that this column holds integers, this one holds dates, this one's a foreign key to another table. If you try to put a string where an integer belongs, the database rejects it. A spreadsheet does the opposite. It accepts anything on write and only figures out what the data means when you read it back — schema-on-read. That's why you can have a column of dollar amounts where someone accidentally typed "about five hundred" in row forty-seven, and nobody notices until the quarterly report numbers are off by twelve percent.
That's the thing Daniel's getting at with data integrity. The spreadsheet's flexibility isn't just occasionally inconvenient. It's structurally incapable of guaranteeing that your data means what you think it means.
And this isn't a bug in how people use spreadsheets. It's a property of the tool. The tool's design says "I will accept anything." The database's design says "I will enforce constraints." Those are fundamentally different philosophies about what data management should be.
Schema flexibility feels like a feature but acts like a bug. It lowers the barrier to entry and raises the ceiling on how wrong things can go.
The ceiling is high. There's a famous case — and I'm not going to name the bank because these stories are legion — but a major financial institution lost something like six billion dollars in a trading desk model because someone copied and pasted the wrong range in Excel, and the error propagated through linked sheets for months before anyone caught it. That's not a user error story. That's a system design story. The system made it easy to make that mistake and hard to catch it.
The spreadsheet is the "trust me" of data management.
And "trust me" doesn't scale past about two people.
Which brings us to the collaborative workflow problem. Daniel said he can't think of any collaborative process where working around a spreadsheet actually benefited the project. That's a strong claim, but I think it holds up if you look at what actually happens in shared spreadsheets.
Let's walk through a concrete example. Marketing team, ten people, shared Google Sheet for campaign tracking. Person A sorts the rows to see which campaigns spent the most. Person B, in a different tab, has formulas that reference specific cell ranges. The sort breaks those references because the data moved. Person C overwrites a formula with a static number because they needed to "correct" something temporarily and forgot to change it back. Person D downloads a copy, works offline on a flight, and emails it around as "Campaign_Tracker_FINAL_v2_REAL_FINAL." Now you have three versions of truth.
Nobody knows which one the CEO is looking at.
And the audit trail is nonexistent. Who changed what, when, and why? The spreadsheet doesn't tell you. Contrast that with even a basic Airtable base, where every record has a revision history, field types are enforced, and you can set row-level permissions so the intern can't accidentally delete the Q4 projections.
Or a Supabase project with a simple front-end. Row-level security is built into Postgres. You can define exactly who can read, insert, update, or delete which rows, based on their role. That's not an advanced feature. That's the default.
That's the point Daniel's making about centralizing around SQL. When you use a database, you get all of this for free. Constraints, permissions, audit trails, referential integrity. When you use a spreadsheet, you have to build all of that with discipline and process and hope. And hope is not a data strategy.
Let's talk about the mechanism that makes spreadsheets feel indispensable even when they're causing all these problems. And I think the VLOOKUP is the perfect symbol for this.
VLOOKUP is one of the most-used spreadsheet functions in history, and it's a perfect case study in why spreadsheets are brittle. The function works by counting columns. You tell it "look for this value in the first column of this range, and return whatever's in the fourth column." If someone inserts a column in the middle of that range, the column count shifts, and VLOOKUP silently returns data from the wrong column. It doesn't throw an error. It just gives you wrong numbers.
Which is worse than an error. An error you notice.
Now compare that to a SQL JOIN. A JOIN is declarative. You say "match these two tables on this column and return these specific fields by name." It doesn't matter if someone adds columns, reorders them, or restructures the table — as long as the named columns exist, the JOIN works correctly. The query describes what you want, not how to find it positionally.
The traditional objection is "but you have to know SQL to write a JOIN.
That's the objection that's dying. SuperAgent, GitHub Copilot for SQL, all the natural-language-to-SQL tools — they can generate those JOINs from plain English. You type "show me which customers bought which products last month" and the AI writes the query, including the appropriate JOINs, with correct syntax. The SQL literacy barrier is falling fast.
The bottleneck shifts. It's not "can I write the query" anymore. It's "do I understand my data well enough to describe what I want.
And that's data modeling. That's the skill that actually matters. Knowing what your entities are, how they relate to each other, what constraints apply. AI can't do that for you because AI doesn't know your business. It doesn't know that a "customer" in your system is different from a "lead" and that the distinction matters for reporting. You have to define that.
We're moving from a world where the technical skill of query writing was the gatekeeper, to a world where domain understanding is the gatekeeper. Which is probably healthier.
The person who understands the business should be the one defining the data model, not the person who happens to know SELECT FROM WHERE syntax.
Let's get into the Airtable SuperAgent thing more specifically, because I think it's the most concrete example of where this is all heading.
What Airtable shipped in January is essentially an AI layer on top of their existing relational database. Users have always been able to create linked records, define field types, set up automations — all the database-backed stuff that makes Airtable more than a spreadsheet. But you still had to build views, write formulas, and manually configure relationships. SuperAgent lets you ask questions in plain English and get answers drawn from the database, with the AI generating and executing the SQL behind the scenes.
The interface is still a grid.
Still a grid. And that's the key insight. They're not asking users to abandon the visual metaphor they're comfortable with. They're keeping the grid as the presentation layer and swapping out the storage and query engine underneath. It's the spreadsheet interface with a database brain.
Which is exactly what Daniel's asking about. Is the visual front-end approach the spreadsheet killer?
I think it's the spreadsheet's future, not its killer. The grid is a good interface for viewing and editing tabular data. It's intuitive, it's information-dense, it's what people know. The problem was never the grid. The problem was that the grid was also the database engine, and it was a terrible database engine.
You're saying the spreadsheet doesn't die. It just becomes a view layer.
It becomes one of many view layers on top of a proper database. Notion is the clearest example of this philosophy. In Notion, a database can be displayed as a table, a board, a calendar, a gallery, a timeline. The grid is just one way of looking at structured data. The data itself lives in a relational structure with typed properties and linked entries. It's a database that happens to have a really nice table view.
That's fundamentally different from Excel or Google Sheets, where the grid is the data.
In a spreadsheet, the data's location is its identity. "The Q3 revenue number is in cell D47." In a database-backed system, the data has identity independent of where it's displayed. "The Q3 revenue number is the value of the Revenue property on the Q3 record." You can display that in a grid, a chart, a dashboard, an API response — it's the same data.
Let's talk about the knock-on effect here. If databases become as easy to spin up as spreadsheets, what happens to the spreadsheet's role as a universal data interchange format?
This is a big one. For decades, the CSV export has been the lingua franca of data exchange between systems. You export a spreadsheet from your CRM, email it to your accountant, they import it into their accounting software. It's clunky, it's lossy, it breaks constantly, but it works because every system can read a CSV.
Because every system can read a CSV, nobody had to agree on a schema.
The CSV is the lowest common denominator. It says "here are some rows and columns, figure out what they mean." But as more tools become database-native and API-driven, that model starts to look antiquated. Why export a CSV from Airtable and import it into Salesforce when you can just connect them via API and have data flow automatically?
The "email me the latest version" antipattern Daniel mentioned.
That pattern exists because spreadsheets are files, and files have to be moved around. Databases are services. They're live. You connect to them, you don't copy them.
That eliminates the reconciliation nightmare. When the sales team has a spreadsheet and the finance team has a spreadsheet and they both claim to show current revenue, but the numbers don't match, someone has to sit down and figure out who has the stale data. That's pure organizational waste.
It's not just waste. It's decision-making based on conflicting information. The CEO looks at two different revenue numbers and has to guess which one is right. Or worse, doesn't realize there are two different numbers and makes a strategic decision based on the wrong one.
Daniel's point about centralizing around SQL — it's not just about technical elegance. It's about having a single source of truth that everyone queries, even if they're looking at it through different interfaces.
That's the vision. One database, many views. Marketing has a dashboard, sales has a CRM interface, finance has a reporting tool — all pulling from the same Postgres instance. Nobody emails spreadsheets around because there's nothing to email. The data is live and consistent.
There's a case study I want to bring in here, because it makes this concrete. Logistics company, mid-size, about two hundred employees. They had twelve departmental spreadsheets tracking inventory, shipments, and orders. Twelve different files maintained by twelve different people, with formulas that referenced each other across network drives. Every Friday, someone would manually consolidate them into a master report for the CEO.
How long did that consolidation take?
About four hours every Friday. And the numbers were always at least a week stale because the consolidation happened on a Friday using data that had been entered throughout the week. So the CEO was making Monday morning decisions based on data that was potentially ten days old.
This is a logistics company. Inventory turns matter. Ten-day-old data is ancient.
They replaced all twelve spreadsheets with a single Postgres database fronted by Retool. Took one development sprint — about two weeks. After that, the CEO could open a dashboard and see real-time inventory numbers. No consolidation, no emailing files, no version confusion.
What was the pushback from the team?
"We've always done it this way." "I don't know SQL." "What if I need to do something the system doesn't support?" All legitimate concerns from people who'd built workflows around spreadsheet flexibility. But within a month, the complaints stopped, because the new system eliminated four hours of Friday drudgery and the numbers stopped being wrong.
That's the pattern. The migration cost is real, but the ongoing cost of not migrating is higher. It's just less visible because it's distributed across everyone's week in small increments.
That's the trap. Spreadsheets externalize their costs. The person who creates the spreadsheet doesn't feel the pain of the person who has to reconcile it, or the person who makes a bad decision based on it. The costs are diffuse and easy to ignore.
If spreadsheets are structurally weaker for collaborative work, and the tools are now good enough that the setup cost objection is fading, why do they persist? What's the real hold they have?
Familiarity is powerful. But I think there's also a legitimate use case that Daniel's argument might underweight. Truly ad hoc, one-off analysis. A journalist gets a leaked CSV and needs to explore it. A researcher downloads a dataset and wants to poke around before deciding how to model it. A founder is playing with pricing scenarios on a flight with no internet.
I was going to raise exactly this. The spreadsheet shines when you don't know what you're looking for yet. When the schema isn't clear, when you're doing exploratory data analysis, when you need to try five different what-if scenarios in ten minutes and throw four of them away. The database's strength is structure and integrity. The spreadsheet's strength is speed of thought.
Those are different things. A database forces you to decide what your data model is before you can do anything useful. That's the right approach for production workflows, but it's friction when you're just trying to understand a dataset.
The question is whether that use case justifies maintaining spreadsheet infrastructure across an entire organization. Most people in most companies are not doing exploratory data analysis. They're doing repeatable, collaborative, integrity-sensitive work. The journalist cleaning a leaked dataset is an edge case, not the daily reality of a marketing team tracking campaign spend.
The spreadsheet has a role, but it's a niche role. It's the sketchpad, not the filing system.
You sketch on a sketchpad. You don't run your company's financial reporting on a sketchpad.
Let's talk about the "two parallel data management products" problem Daniel raised, because I think this is the real organizational cost that nobody budgets for.
It's the hidden tax. Most companies above a certain size have both spreadsheets and databases, maintained by different teams with different skill sets, containing overlapping data that doesn't quite match. The engineering team has a Postgres instance with customer data. The sales team has a spreadsheet with customer data. They should be the same data. They're not.
Reconciling them is someone's part-time job.
If they're lucky, it's someone's part-time job. If they're unlucky, nobody reconciles them and decisions get made on whichever dataset happens to be in front of the decision-maker at the time.
Daniel's proposal is basically: collapse this into one system. Centralize around SQL. Give everyone a view layer appropriate to their role, but have it all query the same database.
The objection historically has been "but the sales team doesn't know SQL and shouldn't have to." That objection is now answerable. They don't need to know SQL. They need a tool that translates their intent into SQL, and we now have those tools.
The remaining objection is "but what if I need to do something the tool doesn't support?" And that's a real concern, but it's also a shrinking category. The surface area of things you can do in a spreadsheet but can't do through a database front-end is getting smaller every year.
Honestly, a lot of the things people think they need spreadsheet flexibility for, they don't actually need. They've just built workflows that depend on spreadsheet flexibility because that was the tool available. When you give them a database-backed tool, they adapt their workflows and often find that the constraints actually help. "I can't accidentally put text in a number field" is a feature, not a limitation.
It's like guardrails on a highway. They feel restrictive until you realize they're keeping you from driving off a cliff.
Most people, most of the time, are not doing the kind of creative data manipulation that requires a schema-less environment. They're entering sales figures, tracking project milestones, managing inventory. Structured, repeatable, collaborative work that databases were literally designed for.
Given all this, what should someone actually do? Let's get practical.
First thing: audit your team's spreadsheets. Not all of them — focus on the ones that are shared by more than two people, used for reporting, or referenced in decision-making. Those are your migration candidates. Start with the ones that cause the most pain. The broken formulas, the version confusion, the Friday-afternoon consolidation ritual.
The audit itself is revealing. Most teams don't know how many critical spreadsheets they have or who maintains them. Just doing the inventory often surfaces risks people were vaguely aware of but hadn't quantified.
Second: if you're building a new internal tool, skip the spreadsheet prototype. Use Airtable, Notion, or a Supabase-plus-Retool stack from day one. The setup cost is now negligible — we're talking minutes to spin up a database-backed base, not days. And you avoid the migration headache later, which is always more expensive than doing it right the first time.
The "we'll just start in Excel and move it later" is the "we'll refactor later" of business operations. It never happens.
It never happens because the spreadsheet becomes embedded in workflows, and migrating means disrupting those workflows, and nobody wants to own that disruption. So the spreadsheet lives forever, accumulating technical debt.
Third insight: invest in data modeling skills, not SQL fluency. AI handles the query generation. What it can't do is understand your business domain and design a schema that accurately reflects it. That's the new bottleneck, and the new competitive advantage.
This is a big shift in how we think about data literacy. For years, the message was "learn to code, learn SQL." Now the message is "learn to think in entities and relationships." What are the things in your business? How do they connect? What constraints apply? That's harder to teach than SQL syntax, but it's also more valuable.
Because the syntax is automatable. The thinking isn't.
The thinking compounds. A well-designed schema makes every query easier, every report more accurate, every integration smoother. A poorly-designed schema makes everything harder forever.
Where does this leave us? The spreadsheet isn't dying — but its role is transforming.
I think the trajectory is clear. The spreadsheet's future is as a view layer on top of a database. Airtable is already there. Notion is already there. Google Sheets is adding more database-like features with every release. The grid UI is too good to abandon — it's information-dense, intuitive, and universally understood. But the backend needs to be a database.
That's not a death. It's an upgrade. The spreadsheet gets to keep its interface and gain all the benefits of a real database — integrity, scalability, permissions, audit trails. The only thing it loses is the ability to be sloppy without consequences.
Which, for anyone who's ever had to untangle a fifteen-thousand-row spreadsheet with inconsistent date formats and broken VLOOKUPs, is not a loss at all.
The question is whether organizations will make the leap before the cost of maintaining two parallel systems catches up with them. Daniel's argument is that the cost has already caught up, and the tools are ready, and the only thing left is inertia.
Inertia is powerful. But it's not a strategy. Go look at your team's most critical spreadsheet. The one that would cause a crisis if it got corrupted or lost. Ask yourself: does this need to be a spreadsheet? The answer is probably no. And the path to something better has never been shorter.
Now: Hilbert's daily fun fact.
Hilbert: During the Tang dynasty, imperial scribes were required to transcribe edicts while standing on one foot if the edict's recipient outranked the scribe by more than three grades, a practice that lasted until a particularly rotund scribe toppled into a ceremonial brazier in the year seven hundred twelve and the emperor abolished it by decree the following morning.
...I have so many questions about the brazier.
That's going to sit with me.
One last thought before we go. The spreadsheet has been the default tool for business data for forty-five years. That's an astonishing run. But the conditions that made it the default are changing. When the setup cost for a database-backed tool is the same as creating a new sheet, when AI can translate business questions into SQL, when the grid interface has been decoupled from the storage engine — the spreadsheet's independence ends. What comes next isn't a spreadsheet killer. It's a spreadsheet that grew up.
Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts. If you enjoyed this episode, tell someone who still emails spreadsheets around with "FINAL" in the filename. You know who they are. Find us at my weird prompts dot com.
We'll be back next week. Try not to VLOOKUP anything in the meantime.
