Troubleshooting Airtable performance

At times, you may encounter issues with your Base’s performance. Indicators of issues with base performance can include one or more of the following:

• Tables, views, or record details loading slowly in the UI

• Automations stuck in pending status or hitting timeouts

• Lagging or failing API requests (500 errors)

• Slow syncs 

For some, base performance issues can be surprising because a base may have been working fine for months or years and then encounter performance issues caused by one or multiple underlying concerns. This article will help explain this complex topic and offer tips on how to improve base performance both proactively and reactively.

Introduction

What affects base performance?

Base performance can be thought of as a queue of tasks that Airtable servers perform on the backend. When users take actions in the base, such as loading a view, editing a record, or creating a record, the actions count as requests in the queue. While the base is able to process requests quickly, it processes one request at a time. So, if too many requests get added to the queue, then the requests at the end of the queue have to wait to be processed. If there is a high volume of requests in the queue, then the last request may take some time to process as it waits for the tasks before it finishes.

Due to the complex nature of performance, a precise limit or expected delay in processing through a backlog of actions to perform is difficult to quantify. Ultimately, it’s important to consider that it is typically automated actions as opposed to human actions which will cause high volume and backup the request queue. 

These include:

• API requests from custom integrations or third-party tools like Zapier

• Syncs

• Automations

For example, let’s say you have a base that includes custom API integrations, third-party integrations, and syncs: 

• If the external integrations are set up to make requests to the base 24/7, then the queue may get overloaded with requests.

• If a human user then accesses the base when the queue is overloaded with integration requests, then they might find the base is slow to load tables or may even crash when taking manual actions in the base. This is because the manual request has to wait behind all of the API requests.

• For this reason, it is important to note that Airtable is not intended to be a backend hosting service/real-time database like Heroku, Parse, Firebase, or MongoDB. Instead, Airtable is primarily designed for use cases where all users will be directly interacting within the Airtable UI. 

• Key takeaway: Use cases like this will lead to constant API requests that can fill up the request queue, slowing down the base.

How does base size factor into performance?

Confusion may occur when base performance is impacted on a base that is not at or near record limits. This is because a base does not need to be “large” in order to have a high request volume – in the example above, a base that has many integrations may not be anywhere near record limits, but could still have an incredibly high request volume if it is constantly receiving requests from integrations in real-time.

That said, base size can still play a part in performance. For example, let’s consider formulas. On a table with 50,000 records, a change that causes an update to a formula field will have to update vastly more records than on a table with only 50 records, this can lead to higher request volume.

In addition, loading a table with 50,000 records is more taxing on performance than loading a table with 50 records.

How does the base schema factor into performance?

Base schema refers to the way data is organized in your base and how the tables and fields relate to each other. The following field types contribute to a more complex base schema by creating dependencies:

• Linked records

• Lookups

• Rollups

• Formulas that reference any of the above fields

Generally, the more complex the base schema is, the more taxing requests will be that reference the schema. Let’s illustrate with an example:

Let’s consider a base that has a "Tasks" table, and multiple select field to designate an assignee. The multiple select field is updated when a new assignee or assignees are added to a task.

In this scenario, only one action is performed when the multiple select field is updated with the assignee(s) responsible for the associated task.

Let’s consider another base that has a "Tasks" table, and instead of a multiple select field, it uses a linked record field to a "People" table to designate an assignee. 

Now, let’s say we want to add a lookup field to the People table in order to display the linked task statuses, a formula field that joins the array of the task statuses, and a rollup field that aggregates the total number of estimated hours for the linked tasks.

When a new assignee is added to a task, the Linked field on the "Tasks" table, as well as the Linked field, the lookup field, the formula field, and the rollup field on the People table all have to be updated. 

What can I do to resolve or prevent base performance issues?

If you are noticing performance issues on your base, or want to avoid base performance issues, then we recommend the following:

Support interaction guidance

If the troubleshooting steps outlined above have not helped to resolve your issue, then feel free to reach out to our support team. Please include any of the relevant information when you submit your help request:

• The base ID that is impacted by performance issues

• Any error messages you are receiving and specific context around the particular issue(s) you are encountering

• Which particular issues you are running into (loading in UI, API failures, etc)

• Context around the use case of your base, and details around its integration architecture (Custom API integrations, No code integrations, etc)

• The date/time range in which the issue occurred, and whether it is ongoing

  • It is great to get as much precision as possible with the date/time

FAQs