Airtable API rate limits: self-hosted alternatives

Why Airtable API rate limits push integration teams toward self-hosted alternatives

An integration or sync job that is throttled by Airtable usually hits one of two ceilings: the per-base request rate, which you should confirm against Airtable's current developer documentation, or the monthly API call cap, which Airtable's plans overview sets at 1,000 calls per workspace per month on Free and 100,000 on Team. Once a nightly sync or a reporting feed crosses either limit, the team must batch requests, spread work over more hours, or move to a higher plan. For teams that need predictable throughput, the short answer is that self-hosted Baserow, Grist and Teable have no vendor-set API quota. Their capacity depends on the application servers, the database (PostgreSQL for Baserow and Teable, SQLite-backed documents for Grist) and the reverse proxy that you run.

Airtable's API caps sit alongside per-seat pricing. Its Team plan lists $20 and its Business plan $45 per user per month, billed annually, on the Airtable pricing page. A service account or integration user may still count as a seat, so ask Airtable how your plan counts automation accounts before you assume the cost is limited to human users. Airtable is a mature product, and for many teams its quotas are an acceptable trade. The question for an integration team is whether the throughput it needs justifies the seats and caps. Self-hosting moves that cost into one-time setup and recurring hosting, database backups, monitoring and administration, and it makes capacity a decision your team controls.

Start by measuring the workload, not the plan. Count the requests your integration makes per base at peak, the total calls per month, and which endpoints it uses for full-table reads versus targeted record updates. Baserow, Grist and Teable each expose REST APIs, so the same job can be redesigned to read changed rows only and to write in bulk. Then confirm, in each vendor's documentation for the version you plan to deploy, whether any built-in throttling or request limit exists and how it is configured. Sizing the database, the application containers and the proxy against that measured peak gives you a capacity figure you can defend in a review, instead of a number set by a pricing tier.

What a throttled integration requires from a replacement

Airtable's limits are set per base and per workspace, so an integration that works around them needs a replacement whose ceilings it can measure and control. The five requirements below cover throughput, volume, batching, service access and burst behavior, and each one has a different owner: the vendor, the database tier or your own servers.

Sustained throughput per base

Airtable caps API traffic at 5 requests per second per base, which sets how fast a sync can run before it is queued or rejected. A self-hosted Baserow, Grist or Teable instance has no such published per-base cap, so the practical ceiling becomes the capacity of your application server and PostgreSQL database. Measure request rate against a realistic table in a staging copy before you cut over. Confirm current limits and any configurable throttles in each product's documentation.

Monthly and volume ceilings

Airtable also caps API calls per workspace per month, at 1,000 on Free and 100,000 on Team. A self-hosted replacement does not meter calls against a plan allowance, so the question shifts to infrastructure cost and capacity planning. Estimate your monthly call volume from current logs, then confirm that your hosting budget covers the peak month, not only the average.

Batched reads and writes

Integrations that cannot batch make one request per record, which multiplies pressure on any per-second limit. Confirm that each candidate's REST API supports batch create, update and list endpoints, along with page size controls and filtered queries. Grist documents a REST API with an interactive API console, which lets you test these calls before you write code against them.

Service account access

Airtable integrations typically run on personal access tokens tied to a user, which complicates offboarding and audit. A replacement should authenticate a non-human account with a scoped token and the same permissions as the sync needs, and nothing more. Baserow's single sign-on is licensed on Advanced and Enterprise, and Grist connects to an identity provider over OIDC or SAML only with an activation key, so confirm how each product issues and revokes API tokens for service accounts.

Predictable behavior under bursts

Bursts from webhooks, scheduled jobs or bulk imports can exceed capacity even when average load is low. Decide where queuing lives, whether in the integration, a message broker or a retry policy with backoff, and load test the database connection pool before go-live. Ask each vendor how the API reports overload so your client can retry safely instead of losing writes.

How Baserow, Grist and Teable compare on API capacity

This table compares how each self-hosted platform exposes its API, what licensing governs it, and which features sit behind a paid license. None of the researched sources publish a requests-per-second figure for the self-hosted APIs, so the practical limit is the capacity of your own servers and database, which you should measure in a test environment before cutover.

Capability	Baserow	Grist	Teable
Core license	MIT for non-premium, non-enterprise features	Apache License 2.0 for grist-core	AGPL-3.0 for the Community Edition
API design	Headless and API first	REST API with an interactive API console	API included in the standalone self-hosted deployment
Database underneath	PostgreSQL, with Django and Vue.js	SQLite-based documents	PostgreSQL, with SQL query access to the data
Horizontal scaling	Docker Compose with separate backend and frontend images, plus Kubernetes with Helm	Single gristlabs/grist container with a /persist volume, documented scaling not in sources	Confirm scaling model with Teable before sizing
Production database step	Use an external PostgreSQL, as Baserow highly recommends	Single-file storage, so plan disk and backup per document	Built on PostgreSQL, so size the external database
Features behind a license	SSO and advanced features need Premium, Advanced or Enterprise	OIDC and SAML SSO, audit log streaming and automations need the full edition	AI features and admin panel need a paid self-hosted plan with a license key
Sustainable Use License	Not applicable	Not applicable	Not applicable
Published requests per second	Not stated in sources, so measure	Not stated in sources, so measure	Not stated in sources, so measure

How to deploy an API-heavy instance and move integrations onto it

This sequence sizes the workload from real Airtable usage, builds a self-hosted Baserow or Grist deployment that can absorb API traffic, and moves integrations across one base at a time with a load test before each cutover.

Measure current Airtable API usage
The integration owner exports the call history the team already holds, such as application logs, middleware metrics or the scripts that call the Web API, and groups calls by base, endpoint, method and hour. Record peak requests per second per base, because Airtable's limit of 5 requests per second per base is the ceiling that the integrations have been working around. Done when each integration has a documented peak rate, a daily call volume and a list of the bases it touches. Confirm current plan caps of 1,000 and 100,000 monthly API calls per workspace on Free and Team with Airtable's plans overview before you rely on them as a baseline.
Size the self-hosted target for the peak load
The platform or infrastructure team converts the measured peaks into requirements for the backend, the database, the cache and the reverse proxy. Self-hosted Baserow has no per-base API cap, so the practical limit comes from the servers you run, the database connection pool and the latency your integrations can tolerate. Document the target concurrency and the headroom you want above the measured peak. Done when the sizing sheet is signed off by the integration owner and the infrastructure lead, and any number you adopt is traced to your own measurements or to a vendor document you have read.
Deploy Baserow with external PostgreSQL
The platform engineer runs the baserow/baserow image with an external PostgreSQL database instead of the internal one the image bundles by default, which Baserow advises against for production. The database runs on storage with backups and monitoring configured by your database team, and the Baserow services connect to it through environment variables. Done when the instance starts, the admin account signs in, a test table is created and a backup restore has been tested on a copy of the database.
Scale backend and frontend containers horizontally
The platform engineer moves from the single container to separate backend and web-frontend containers, either with the Docker Compose setup Baserow documents or with its Helm chart on Kubernetes. Replicas of the backend are added behind a load balancer to match the sizing sheet, and Redis and PostgreSQL capacity is checked against the same figures. Done when health checks pass on every replica, a sustained test request rate reaches the target without errors, and the team can scale the replica count without downtime.
Add a reverse proxy with rate limits
The platform engineer places a reverse proxy in front of Baserow and sets per-client or per-token request limits, so one runaway integration cannot starve the others. Limits are set by integration, not by base, and they are logged so the team can see which client is hitting them. Grist, if it is part of the plan, is deployed in the same way: its gristlabs/grist image listens on port 8484 and keeps its data in a /persist volume that the proxy should route to and back up. Done when a test client exceeding its limit receives throttling responses while the other clients continue to succeed.
Repoint integrations one base at a time
The integration owner moves each integration to the self-hosted instance after its base has been imported with Baserow's Airtable importer, which works from a public share link and handles one base at a time. Formula, lookup, rollup and collaborator fields, automations and interfaces are rebuilt before the switch, and the integration's API credentials and endpoints are changed in a staging copy first. Done when each base has a row count and attachment count that match the source, and the integration reads and writes correctly against the new base.
Load test and cut over
Before production traffic moves, the team runs a load test that replays the measured peak pattern against the new instance, including bursts, and watches latency, error rates and database connections. Any failing threshold goes back to the sizing step. When the test passes, Airtable write paths are paused for the affected base, a final delta import is run, and traffic is switched with a documented rollback path to the Airtable base. Done when the load test report is filed, the rollback has been rehearsed, and the Airtable base is set to read-only only after the new instance has run cleanly for the agreed observation period.

How to size the database and protect the API from runaway clients

The main sizing question on a self-hosted instance is what your integrations will actually send, not how many calls a vendor allows. On Airtable, a throttle of 5 requests per second per base and a monthly call cap are fixed by the vendor. On Baserow, Grist or Teable, the limit is whatever your servers can sustain, and four cost drivers set it: request volume, payload size, attachment transfer and database connections. Chatty integrations that poll every table, large record payloads with many linked fields, attachment downloads routed through the application server, and worker processes that each hold PostgreSQL connections all compete for the same CPU, memory and network. Benchmark your own workload with a replay of realistic API calls from your integrations, and record p95 latency, error rates and connection counts. Confirm the rate-limit and request-size behavior of each product with its vendor documentation and release notes before you treat any number as settled, because API behavior changes between releases.

Protection works best in layers. Put a reverse proxy in front of the API and apply per-token rate limits, so one misbehaving script cannot starve the others. Route bulk imports and large exports through a queue that runs during off-peak hours, instead of letting them run as direct API traffic. Make every client honor HTTP 429 responses with exponential backoff and jitter, and have integration owners confirm this in code review. For attachments, serve downloads from object storage or a CDN where the product supports it, so file transfers do not occupy application workers. Keep the proxy and API logs so you can attribute load to a specific token or integration.

Watch PostgreSQL connections as an early warning. Track active connections, connections waiting on locks and idle-in-transaction sessions, and alert before the pool is exhausted. A connection pooler such as PgBouncer in front of PostgreSQL is a common choice when many API workers run in parallel, but confirm its compatibility with your chosen product's database usage first. Set a rule that any new integration gets its own API token, a documented expected volume and a test run against staging before production. That keeps runaway clients visible and gives you a clear point to throttle or revoke access.

Which API features depend on the license you choose

Baserow is open core. Its non-premium and non-enterprise features sit under the MIT License, and the paid self-hosted license types add capabilities on top. Self-hosted Baserow offers three paid license types: Premium, where seats are assigned manually to users, Advanced, which grants paid access to users on the instance, and Enterprise, which is priced through sales. An instance can run only one license type, so an integration plan has to match the license that instance holds.

Premium seat model: Seats are assigned to named users, which suits small integration teams with a fixed set of accounts.
Advanced access model: Paid access applies to users on the instance, which changes how service accounts and integration users are counted.
Single sign-on: SAML and OAuth 2.0 providers, plus generic OpenID Connect, are available on Advanced and Enterprise with an activated license.
Enterprise terms: Enterprise is quoted through sales, so ask for the written list of API-related entitlements.
Single license per instance: Mixing license types on one server is not an option, so plan separate instances for different tiers.

Before you commit, ask Baserow in writing which API endpoints, token types and automation features are covered by each license type. Confirm how service tokens are counted against seats.

Questions teams ask before changing their Airtable integrations

What drives the cost of self-hosting an API-heavy Baserow or Grist instance?

The cost is driven mainly by the servers and database behind the API, not by per-call fees. Recurring costs include the compute and storage you run in your own cloud account or data center, backups, monitoring, patching and the staff time to administer the instance. Request volume, peak concurrency, record count, attachment storage and how many integrations poll the API all push sizing up. Baserow recommends an external PostgreSQL for production, and its Docker documentation describes horizontally scaled deployments with Docker Compose or Kubernetes Helm, so the database and web tier can be sized separately. Ask any quote to itemize these components and to state which licenses, if any, are needed for the features your integrations rely on, such as single sign-on on Baserow's paid plans.

How long does it take to migrate Airtable integrations?

The duration depends on the scope, so it has to be quoted in writing before work starts. The main variables are how many integrations exist, how many bases and tables they touch, how much logic lives in Airtable formulas, automations and scripts that must be rebuilt, and how many owners need to test and sign off. DeployOpen plans most engagements as fixed scope, with deliverables and timelines agreed in writing before work begins. Ask the provider to break the schedule into inventory, endpoint mapping, parallel running, cutover and rollback, and to state which of those steps the client's own teams must staff.

Can our in-house team migrate Airtable integrations on its own?

Often yes, for a small number of integrations with clear owners and modest data volumes, provided the team has someone who can administer Docker or Kubernetes, manage a PostgreSQL database and write API clients. Teams usually struggle with the less visible work: discovering every integration that calls the API, handling retries and pagination, planning for the throughput the new server must sustain, setting up backups and monitoring, and testing cutover without losing records. Baserow's importer and Grist's Airtable import cover data movement for one base at a time, but they do not rebuild formulas, automations or external connections. A useful test is whether the team can name the owner, schedule and rollback plan for each integration before the first cutover.

What does DeployOpen need from our team to start?

DeployOpen needs access to the environment where the self-hosted platform will run, such as the cloud account, data center or air-gapped network, along with the people who approve changes there. It also needs call logs or a usage export from Airtable so the integration inventory reflects real traffic, and a named owner for each integration who can explain its purpose, schedule, data fields and acceptable downtime. Security and compliance contacts should be identified early so access rules, encryption and retention decisions are made once. Scope, deliverables and timelines are agreed in writing before work starts, so these inputs feed directly into that document.

Can we use Airtable's Web API for a one-time data extract?

Yes, the Web API can be used for a one-time extract, but it is bound by the limits that drive this migration. Airtable documents a rate limit of 5 requests per second per base and monthly API call caps by plan, which the plans overview lists as 1,000 calls per workspace per month on Free and 100,000 on Team. A full extract of a large base therefore has to be paced, and it may need to run across more than one billing period on lower plans. Airtable also does not export a whole base as one file, so each table is downloaded as its own CSV from a view. Attachment links can expire, so download attachments during the extract. Confirm current limits on the pricing and plans pages before scheduling the run.

How do we confirm current Airtable and self-hosted API limits before committing?

Confirm Airtable's limits directly from the current plans overview and pricing pages on the date of your decision, because plan terms change. For self-hosted options, the limits come from your own servers, reverse proxy, database and any gateway in front of the API, so measure them rather than relying on a vendor figure. Load-test the target instance with a copy of your real request pattern, including bursts and polling intervals. Check the release notes of the platform you choose, since Baserow, Grist and Teable publish frequent releases. Ask any provider to document the throughput it tested, the hardware profile and the conditions under which the results were measured.

Do self-hosted Baserow, Grist and Teable APIs have a built-in rate limit?

The REST APIs are limited by the servers and proxies you run rather than by a per-base cap set by the vendor. Grist offers a REST API with an interactive API console, Baserow describes itself as API first, and Teable lists an API among its standalone self-hosted features. Whether any built-in throttling is enabled, and how it is configured, should be confirmed in each product's documentation and your own test environment. Plan for rate control at the reverse proxy, in your integration code and in the database connection pool, and monitor queue depth and error rates so that a runaway client cannot degrade other users.

Evidence that the API tier is operated under control

Once Baserow, Grist or Teable serve integrations that used to run against Airtable's per-base limit, the API tier becomes a service you run and must be able to show is controlled. The cards below list the records that demonstrate capacity, throttling, database health, access and change control. DeployOpen prepares this evidence inside your environment, but independent auditors and certification bodies are the ones who issue any assessment.

Load test reports

Load test reports show the request rate, concurrency and response times the self-hosted API sustained before any integration went live. Keep the test script, the target endpoints, the data volume used and the pass criteria with each report. Confirm that tests ran against a production-like deployment, such as the external PostgreSQL and multi-container layout, rather than the single-container default. Re-run them after each Baserow, Grist or Teable upgrade, because the limits you measured belong to that exact build and hardware.

Rate limit configuration exports

Rate limit configuration exports record every throttle that sits in front of the API: reverse proxy limits, application-level limits and per-client quotas. Export them as versioned files so a reviewer can compare what was configured on a given date with what was in force during an incident. Include the rules for bulk endpoints, since a single large import can consume capacity meant for every other integration. Ask your team to state which limits Airtable imposed, so the replacement policy is explicit rather than inherited by habit.

PostgreSQL monitoring records

Database monitoring records show connection counts, query latency, lock waits, replication lag and disk growth over time. These are the first signals that API load has outrun the database, which is the most common bottleneck once the application tier scales out. Keep alert thresholds and the on-call responses to them with the metrics. Confirm with your DBA which PostgreSQL version and backup schedule the monitored instance uses, because those facts belong in the same evidence set.

Access logs for service accounts

Access logs for service accounts show which integration token called which table, at what rate and from which network address. Airtable's per-base limit made such logs less useful for capacity planning, so they now serve a second purpose: proving that each integration used only the access it needed. Review token scopes and rotation dates on a fixed schedule and record each review. Confirm how long your reverse proxy and application logs are kept and where they are stored, since those retention settings decide what an auditor can see later.

Change records for repointed integrations

Change records document each integration moved from Airtable's API to a self-hosted endpoint, including the old and new base URLs, the token that replaced the Airtable credential, the test results and the approver. They show when traffic changed and who authorized it, which matters when a data discrepancy appears after cutover. Keep rollback steps beside each record. Where Airtable's per-workspace monthly call cap previously shaped job schedules, note the schedule change as its own entry so the old constraint is traceable.

Backup and restore test records

Backup and restore test records show that the database holding API-written data can be recovered within the time your business accepts. A backup that has never been restored is an assumption, not evidence. Record the restore date, the target environment, the data checked after restore and any gap between the last backup and the failure point. Include the Grist document storage or Baserow media files in the same test, since records and attachments are restored together. Ask your provider to confirm the recovery targets they will commit to in writing.

How DeployOpen sizes and hardens self-hosted API platforms

DeployOpen plans, implements, hardens and supports self-hosted platforms inside your own infrastructure, so API throughput is set by servers you control rather than by a vendor's per-base limit. We start from your integration's call pattern and the controls your organization needs, then document what we build so your team can operate it.

How we scope

We inventory every integration that calls the Airtable API, including call volume, peak bursts and the bases involved.
We agree on the target platform, whether Baserow, Grist or Teable, and the hosting environment in writing before work starts.
Engagements are fixed-scope, with deliverables, timelines and any ongoing retainer for support agreed in advance.

How we build

We size application servers, PostgreSQL and caching for the request rates your integrations generate, and document the assumptions.
We configure a reverse proxy with rate limiting, timeouts and access logging for each API consumer, using keys or tokens you own.
We load test the deployment against your real call patterns and record results before any cutover.

How we hand over

You receive architecture notes, sizing worksheets, configuration files and runbooks for scaling and API key rotation.
We document the backup and restore procedure for the database and attachment storage, and test a restore with your team.
We walk your engineers through monitoring of request volumes, error rates and resource use, so limits can be tuned in-house.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, covering platform releases and configuration changes.
We can repeat load tests after schema changes, new integrations or growth in record counts, and report the findings.
Ask us to confirm current rate and resource behavior for the exact version you plan to run before committing to a sizing.