View profile

Airtable vs sheets

Today on the stream I'm excited to welcome Ben L Collins, Google Apps expert & Sheetscon founder
Airtable vs sheets
By Aron Korenblit • Issue #40 • View online
Today on the stream I’m excited to welcome Ben L Collins, Google Apps expert & Sheetscon founder to talk about Airtable vs Sheets.
You can add this invite to your calendar to tune in live or follow on twitch to get notified every time we’re live.
Next week, I’ll welcome Chris Messina to chat about Alfred App! Full calendar of future guests here. You can add all future streams to your calendar by clicking here (it auto updates!).
Replays always available the next day on Youtube.
Onto the update…

I’ve been dancing around this subject a lot but I felt like this week with Ben coming, it was a good time to talk about Airtable (relation databases broadly) vs Spreadsheets.
Note I’ll write about the cons of User generated software in the future – y'all really didn’t like that piece :)
Spreadsheets are intuitive, friendly, ubiquitous and a terrible place to hold structured information. I say this as someone who spent the formative years of my career deeply engrossed in spreadsheets. There was a time when I could and would spend hours playing in a spreadsheet (without touching my mouse, obviously). They’re great for some things but awful for a lot of what people use them for.
Let’s explore why.
Spreadsheets hold information in cells. And cells can be referenced through two attributes: rows and columns. It is not defined by anything else. Every piece of information you’re tracking is simply the intersection of a row and a column. B8 references whatever is in the cell that intersects columns B and row 8. Beyond “data that is in B8”, sheets have no concept of what information you’re putting into them. Yes you can input dates and formulas such that the value in the cell reflects what you need. But to the spreadsheet whatever you put into B8 has no additional structure, there is no schema to reference to say B8 is actually the date at which we launch this or that campaign.
So to balance that out, you start defining a schema without realising through tabs/files/headers whatever. You start by making the first row a header to define what goes into each column, B ➡ First name, C ➡ Last name of every person who’s joined your last event. But then oh no, you have multiple events! So you either add a column for EVENT or create new tabs to denote new events. To calculate total number of attendees, you end up with multiple vlookups (you should be using at Index Match’s) or sum ifs.
What you’re ultimately creating is a spreadsheet marauding as a database! A great example of what this looks like is when we helped a car dealership migrate off of spreadsheets. They wanted to say “for this brand, in this build, for this model, in this year, it costs X or isn’t/is available” but since sheets can only contain two dimensions, they had to map models as tabs and years as separate files (every year is a new file!).
Furthermore, you can’t define ahead of time what values you’re going to put in a cell (or a range). In a relational database, you’re asked up front “are these going to be dates? URLs?” while in a spreadsheet you’re free to put in whatever at any time. By knowing what’s going in advanced databases can create these fancy views: calendar or kanban or whatever else they want.
Given the limitation that cells only have two dimensions with no prior on what’s going into them, users resolve to layouts as an information layer. Sheets cannot “understand” calendars so you make the layout a calendar like so:
There’s a whole cottage industry around selling templates to make it easier to recreate these on a regular basis!
Let’s be clear, I absolutely love spreadsheets. I love a good spreadsheet, I love a terrible spreadsheet. I, like most folks, default to a spreadsheet for most things. Not only that, I also strongly believe that there are so many great use cases for which a spreadsheet is great (mainly around accounting/finance). If two dimensions is all you need (fiscal year – month & value) then by all means a spreadsheet is perfect.
The use cases where spreadsheets should be preferred are almost mutually exclusive of those where databases are optimal. The real challenge is that spreadsheets are much better understood and represent the default for everything (here’s an especially egregious case where they were used for contract tracing).
All of this is why on the stream with Ben today we won’t be debating spreadsheets vs Airtable (relational databases). We’ll discuss when each should be used and how to make sure we’re using them effectively (but that would be a much less compelling title so we kept Airtable vs spreadsheets).
In fundraising news
The “Airtable” ecosystem is growing. Some are building apps on top of Airtable while others are building apps outside of Airtable but using Airtable as the backend. I wanted to highlight two today who have recently raised funds and I’ll dedicate some words & stream time to folks building apps within Airtable (who have not raised funds).
Softr scores $2.2M seed for its no-code website and web app platform powered by Airtable – TechCrunch
Stacker raises $1.7M to help nocoders build apps from spreadsheets – TechCrunch
Did you enjoy this issue?
Aron Korenblit

A weekly long form newsletter about working harder not smarter written by Aron Korenblit

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue