Skip to main content

Airtable is an amazing tool for quickly prototyping ideas.



After working helping many teams build prototypes or production applications that use Airtable as a database, we compiled the six best practices that we see make these projects not only faster to build, but easier to maintain and scale. For instance:







  1. Setup a Dev Environment: Things can break as you build new features or adjust your base schema. So duplicate your base to create a “Dev” environment in case you need to revert back. This allows you to build with confidence.




  2. Use a naming convention to delineate lookups and calculated fields: Lookups and calculated fields can make it hard to maintain a clean data model and understand how your data is changing. So use a naming convention that helps identifies these field types (like and underscore → _)




  3. Create a quick README doc: It’s surprising how many teams don’t know about all the automations and integrations that are changing data within their base. So take a moment after each integration is built to document it for your team using the Airtable Description App.




Get all the best practices and details by checking out our blog post:







I think you’ll find these tips are as true for low-code implementations as they are for applications built in full code.



Hope you all find this helpful 🙂

Another great article! Thanks! 🙂

Great article!



I heartily agree with your these points, and thought I’d add some of my thoughts.



A dev environment is essential. I like to give my dev bases a different color/shade from the production base so that it is easy to tell them apart. When switching between bases, it is easy to get confused when everything looks the same.



Unfortunately, when integrating with third party tools having a separate dev environment can be difficult, because you have to create all the integrations with both the dev environment and the production environment.



Naming conventions are also essential when a base has many tables and fields. I recommend naming all tables and fields carefully, not just calculated ones. The names of your tables and fields are an important part of your user interface and documentation.



If you create a readme, make sure that you maintain it. Don’t make it so detailed that it is a burden to maintain. Inaccurate documentation can be worse than no documentation at all! Also remember to distinguish “user” information from “developer” information. Users need to know far less information than a developer who needs to maintain the system.



The article lists two main limitation when deciding whether to use Airtable: record limits and REST API rate limits. Records limits are one of the first considerations when evaluating the suitability of Airtable for a situation. You may need more records than you thought if you need a junction table or if you need to convert a field into a linked record.



On the other hand, rate limits for the REST API are important if and only if you are using the REST API. If you are depending on the REST API with anything but a token number of users, you need a system that includes caching (such a Sync, Inc.)



One additional limitation is the fact that Airtable requires an active internet connection, and it has a limited feature set on mobile devices. Make sure that the Airtable features that you need are available in the environment that you will be using.

Great article!



I heartily agree with your these points, and thought I’d add some of my thoughts.



A dev environment is essential. I like to give my dev bases a different color/shade from the production base so that it is easy to tell them apart. When switching between bases, it is easy to get confused when everything looks the same.



Unfortunately, when integrating with third party tools having a separate dev environment can be difficult, because you have to create all the integrations with both the dev environment and the production environment.



Naming conventions are also essential when a base has many tables and fields. I recommend naming all tables and fields carefully, not just calculated ones. The names of your tables and fields are an important part of your user interface and documentation.



If you create a readme, make sure that you maintain it. Don’t make it so detailed that it is a burden to maintain. Inaccurate documentation can be worse than no documentation at all! Also remember to distinguish “user” information from “developer” information. Users need to know far less information than a developer who needs to maintain the system.



The article lists two main limitation when deciding whether to use Airtable: record limits and REST API rate limits. Records limits are one of the first considerations when evaluating the suitability of Airtable for a situation. You may need more records than you thought if you need a junction table or if you need to convert a field into a linked record.



On the other hand, rate limits for the REST API are important if and only if you are using the REST API. If you are depending on the REST API with anything but a token number of users, you need a system that includes caching (such a Sync, Inc.)



One additional limitation is the fact that Airtable requires an active internet connection, and it has a limited feature set on mobile devices. Make sure that the Airtable features that you need are available in the environment that you will be using.


Great additions @kuovonne,



These two in particular are very helpful for anyone building on Airtable:





👆 Definitely use different colors / icons to help you distinguish between your dev and prod bases. It is easy to get the wires crossed in Airtable and a visual reminder is very helpful.





👆 Completely agree here. Keeping documentation simple and accurate is far more important than thorough but inaccurate. A quick bullet point list can do the trick. Something like:



- Typeform → `applications` table


- `applications` table → Zapier → Mailchimp


And thanks for you support on using a Cache like Sync Inc 🙂



Eric

Reply


Terms & Conditions