Indeed, products evolve in many ways but typically only in ways that they can actually evolve practically. Given the current Airtable experience and features, they’re sort’a in a box not unlike the box Google Sheets finds itself in.
As I said here, recently…
A Google sheet with 5 million cells (populated or not) looks and feels a lot like Airtable with 50,000 records. What does that indicate? It tells me that the tipping point is not likely the underlying architecture; rather, it’s the limitation of the underlying compute stack typically employed. My mostly uninformed technical assessment is that – all things constant – neither 5 million cells or 50,000 records will ever be performant given today’s commonly available consumer devices.
And, so what do I mean by “all things constant” in this assessment?
The user experience and features represent what we know Airtable to be for use cases under 50,000 records. And depending on the number of fields, especially formula fields, the practical ceiling is dynamically lower than 50,000 records.
If you want to push the record limit to 100,000, or a perhaps a million records, something – perhaps many things – about the product experience need to change. As such, users must be willing to give up some features and work differently, ergo - there’s a good probability that it won’t be Airtable as you know it.
As such, feel free to indicate here (to help the Airtable design team) understand the central and bare minimum UI and UX features that you cannot live without in a product that has vastly more scale. If you think the technical complexities are challenging, try getting every user to agree to this new [scalable] product definition. :winking_face:
Have you noticed that most databases that scale do not look or feel like Airtable?
There’s a pretty good reason. They can’t because they support millions of records.
What’s the Remedy?
I hate to crap all over customer requirements that are generally reasonable and helpful to a growing product, so I’ll toss this idea out because I’ve actually mimicked this with a one-million record data set.
- Imagine a plugin architecture that allows you to select arbitrary database back ends like Firebase, or ElasticSearch.
- The plugin would automatically cache into and out of Airtable’s current datastore records that are immediately relevant.
- As the user moves through the dataset, records would paginate to provide viewing access, shifting the relevant “window” as needed.
- The plugin would be a premium service extension and users would be responsible for their own data storage and bandwidth costs with their chosen datastore provider.
Indeed, take just one feature; search. Imagine how this would need to change to perform instant findability across a million records of which less than 50,000 are actually in view or memory.
