Contents x
    Troubleshooting Airtable base performance
    • 16 Jun 2023
    • 7 Minutes to read
    • Print
    • Dark
      Light
    Contents

    Troubleshooting Airtable base performance

    • Updated on 16 Jun 2023
    • 7 Minutes to read
    • Print
    • Dark
      Light
    Article Summary

    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 startling 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

    Plan availabilityAll plan types
    Permissions

    Owners/Creators - Although all users can help to ensure the best possible base performance by identifying potential issues, fixing the underlying issue or restructuring a base can only be performed by users with owner/creator permissions.

    Platform(s)Web/Browser, Mac app, Windows app, and mobile apps
    Related reading


    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:

    Scenario 1: Adding an assignee to a task via a multiple select field type:

    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.

    Scenario 2: Adding an assignee to a task via a linked record field type:

    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. 

    Comparing scenarios and key takeaways

    The first scenario is much less taxing on Airtable base performance than the second scenario. This isn’t to dissuade you from structuring out a more complex base schema where necessary, but rather, to illustrate the importance of considering base schema with regard to base performance. This is especially important when the requests that are referencing complex and interdependent schema are automated via API, automations, and/or syncs.


    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:

    Integration architecture

    One of the most common causes of performance issues is due to request volume from APIs. These can be from custom integrations, "no code" integration tools (Zapier/Make), as well as other tools that integrate directly with Airtable (Stacker/Softr).

    • Where possible, decrease the number of requests being made to the base from integrations
    • Consider the frequency of these integrations, and where possible, consider adjusting the timing of integrations so that requests don’t back up the queue while human users are on the base
    • If possible, consider syncing needed data to another base and make requests to that base, leaving the original base to be unencumbered by constant requests (this works better for GET requests)
    Automations

    Similar to integrations, automations running in near real-time (especially when coupled with integrations) can strain a base.

    • Remove any unneeded automations and/or consider configuring your automations to batch updates outside of working hours 
    • Consider adjusting automation triggers where possible. For example, if you are using a time-based trigger, consider decreasing the frequency and setting the trigger to run outside of normal working hours at your organization. 
    • Additionally, consider changing automations that trigger When a record is updated to instead utilize the When a record matches conditions trigger type. Often, this will decrease the number of automation runs needed.
    Syncs

    Syncing is another computed action that can cause strain on a base under certain conditions, as syncs typically deal with larger volumes of data and run on a consistent cadence.

    • Remove any unneeded syncs.
    • If you have a complex ecosystem of syncs with many syncs pulling from a base that human users work in, consider syncing data into a secondary base that serves as only a sync source to downstream bases, allowing the original base to only have to sync out to one destination.
    Formulas

    Formulas, especially time-based formulas that include the NOW() function, can be very taxing on large bases. 

    • Remove any unneeded formula fields
    • Instead of using NOW(), use the TODAY() function to decrease the request load caused by time-based formulas
    Base schema
    • Consider whether your requests are impacting complex base schema interdependencies and causing a “chain reaction.” 
    • Remove unnecessary lookups, rollups, and any formula fields that are referencing linked records, lookups, and rollups.


    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 the following information when you submit your help request:

    • The base ID that is impacted by performance issues
    • 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
    Was this article helpful?
    What's Next