#419 2012 · Airtable (Howie Liu, Andrew Ofstad, Emmett Nicholas) · Software / productivity tools
Airtable gives non-technical teams a real database by making sure it never looks or acts like one
the problem
The more powerful tool requires skills most of the people who need its power don't have
background
By the early 2010s, relational databases could do things spreadsheets structurally couldn't — linking related records across tables, enforcing field types, building custom views over the same underlying data — but using one meant knowing schema design and often SQL, skills far outside what most office teams, marketers, and small-business operators had. Spreadsheets, meanwhile, were universally usable precisely because they demanded no special skill, but that same simplicity kept every spreadsheet flat: no real relationships between sheets, no structured field types, no way to view the same data multiple useful ways without duplicating it.
Howie Liu, who had watched at Salesforce how many people used spreadsheets purely as makeshift organizational tools rather than for calculation, concluded the barrier wasn't that ordinary users didn't want database power — it was that every database product asked them to learn what a database was before they could use one. He and co-founders Andrew Ofstad and Emmett Nicholas spent roughly three years building a product that would give people the power without asking them to cross that line.
what everyone would do
Build a more powerful relational database product and invest in making it easier to learn -- better documentation, simplified schema tools, a gentler onboarding flow -- the standard response to a capability gap, which still requires users to eventually understand what a database is before they can benefit from one.
what they saw
Liu saw that the barrier to database adoption wasn't a lack of demand for structured, related data among ordinary users -- he'd already watched people jury-rig spreadsheets to do database-like work -- it was that every existing database product made users cross a skill threshold (schema design, often SQL) before they could use it at all. The fix wasn't making that threshold easier to cross, it was building a product powerful users never had to know they were crossing.
the move
Airtable, launched in 2015 after roughly three years of development, built an actual relational database as its underlying engine — typed fields, linked records across tables, multiple structured views of the same data — but wrapped it entirely in an interface that looked and behaved like a spreadsheet grid: rows, columns, click-to-edit cells, drag-to-resize, the exact interaction model of Excel or Google Sheets. Users built what were functionally relational databases without ever encountering the word 'schema' or writing a query.
why it works
By building a genuine relational database underneath but wrapping it entirely in the exact interaction model of a spreadsheet -- rows, columns, click-to-edit cells -- Airtable let users build linked, typed, multi-view data structures using skills they already had, never encountering the vocabulary or concepts that make databases intimidating to non-technical users. Because the interface asked for zero new learning, adoption wasn't gated by training the way a real database product's onboarding always is, converting what other companies treated as an education problem into a design problem Airtable could solve once in the product itself.
the payoff
By 2018 Airtable had reached roughly $20 million in revenue with adoption across 80,000 organizations including Netflix and WeWork, and its funding rounds tracked the traction directly: a $100 million raise in September 2018 valued the company at $1.1 billion, rising to an $11 billion valuation by its 2021 Series F — a trajectory built entirely on non-technical teams adopting database-grade tooling without ever being asked to learn one.
where it breaks
This approach only works when the underlying power can genuinely be exposed through the simpler interface's existing interaction patterns -- some database capabilities (complex joins, advanced querying, computed relationships) may have no natural spreadsheet-shaped analog, forcing a tradeoff between how much power stays hidden and how disguised the product can remain. It also risks confusing users who eventually do need the full power and complexity the interface was designed to hide, since a product that works hard to not look like a database can make it harder for users to find or understand the advanced features once they're ready to use them.
what came after
Airtable's spreadsheet-shaped database interface became the reference design for an entire category of 'no-code' database and app-building tools that followed it, demonstrating that the barrier to broader database adoption had been interface complexity, not a genuine lack of demand for relational data structure among non-technical users.
references
- [1]AirtableWikipedia, 2026en.wikipedia.org
- [2]Move Slow and Make Things: Airtable's Howie Liu Built A $1B Software Giant Emphasizing Substance Over SpeedForbes, 2018forbes.com
- [3]How Airtable Became a Unicorn by Reinventing the SpreadsheetNira, 2023nira.com