Airtable API limits, measured
A controlled head-to-head of both REST APIs on an identical six-field schema and byte-identical payloads. At 1,000 records — the most an Airtable Free base can hold — Zite was faster on every operation we measured, by 13× to 16× on bulk create, update and full scan. We then ran Zite on its own up to 100,000 records, where the gap gets bigger.
- Faster bulk create at 1,000 records
- 13.7×Faster bulk create at 1,000 records
- Faster full table scan
- 15.9×Faster full table scan
- Faster to import 100,000 records
- 22×Faster to import 100,000 records
- Requests to count 50,015 matching records
- 1 vs 501Requests to count 50,015 matching records
Airtable's API limits
The limits you run into building on the Airtable API, and what Zite does instead. Checked against the live APIs and the docs in August 2026.
| Limit | Airtable | Zite |
|---|---|---|
| Requests per second, per baseThis is the one most integrations hit, since most of them work against a single base. | 5 | 30 |
| Records per write requestAirtable documents a 10-record maximum for create and update. We measured 25 being accepted and used 25 throughout, because the larger batch makes Airtable finish sooner. | 10 documented · 25 accepted | 100 |
| Records per read page | 100 | 2,000 |
| API calls included per monthAirtable's monthly allowance is per workspace, not per base or per user. | 1,000 Free · 100,000 Team · Unlimited Business+ | Not metered |
| Behaviour once the monthly quota is spent | Throttled to 2 requests/sec until the month resets | No monthly cap to exhaust |
| Rate-limit response | 429, then a 30-second lockout | 429 with backoff |
| Count records matching a filter | No endpoint — page the entire matching set | One request |
| Pagination model | Opaque cursor — strictly sequential | Numeric offset — pages can be fetched in parallel |
Sources: Airtable API rate limits · Airtable API call limits · Zite database API
What each API allows
Five differences between the two APIs account for every number on this page. We measured each one against the live endpoints instead of reading it off the docs — in one case the documented value was wrong.
| Capability | Zite | Airtable | Advantage |
|---|---|---|---|
| Records per write request | 100 | 25 | 4× |
| Records per read page | 2,000 | 100 | 20× |
| Rate limit (requests/sec) | 30 | 5 | 6× |
| Server-side filtered count | Yes | No | — |
| Pagination model | Numeric offset | Opaque cursor | — |
Pagination is the hardest one to work around. Zite returns a numeric offset, so you can ask for pages 1 through 50 at the same time. Airtable returns an opaque cursor that only arrives with the previous page, so reading a large table is strictly sequential however much concurrency you have.
Throughput at 1,000 records
Both platforms ran the same operations on the same data, each at its own documented rate limit. 1,000 records is the ceiling here because an Airtable Free base cannot hold more — so this is the largest table where both sides could be measured directly.
Records processed per second
higher is better- Zite
- Airtable
View as table
| Operation | Zite | Airtable | Ratio |
|---|---|---|---|
| Bulk create | 1,479.6 | 108.2 | 13.7× |
| Bulk update | 1,641.0 | 119.5 | 13.7× |
| Full table scan | 2,905.9 | 182.7 | 15.9× |
| Count filtered (wall time) | 331 ms · 1 req | 2,380 ms · 5 req | 7.2× |
Zite is faster per request, even before rate limits
Throughput mixes two things: how fast the server responds, and how many requests you are allowed per second. Latency measures only the first, and rate limits do not affect it. Zite is 1.5× to 3.5× faster here too, so this is not just a bigger quota.
Median request latency at 1,000 records
lower is better- Zite
- Airtable
View as table
| Operation | Zite | Airtable | Ratio |
|---|---|---|---|
| Fetch one record | 162.0 | 437.6 | 2.70× |
| First page | 360.5 | 555.8 | 1.54× |
| Filtered query | 304.5 | 518.1 | 1.70× |
| Sorted query | 366.2 | 546.6 | 1.49× |
| Write request | 325.2 | 1,154.5 | 3.55× |
| Update request | 227.1 | 565.0 | 2.49× |
The write-request comparison understates the gap. Zite’s request completed in 325 ms while carrying 100 records; Airtable’s took 1,155 ms carrying 25. Per record that is 3.3 ms against 46 ms. Zite also returns roughly 2.15× more bytes per record than Airtable, and still finishes a full scan 15.9× sooner.
What happens at 100,000 records
Airtable Free caps a base at 1,000 records, so the head-to-head stops there. We ran Zite on its own up to 100,000 records. Write throughput kept climbing — 1,480 → 2,748 rec/sec — because bigger runs spread the per-request overhead further. Read throughput peaked at 10,000 records and dipped a little at 100,000, but never dropped below 3,500 rec/sec — seven times the fastest Airtable can read at all. Its 5 req/sec limit and 100-record pages cap it at 500 rec/sec whatever the table size.
Zite throughput by table size
measured · higher is better- Bulk create
- Full scan
View as table
| Table size | Bulk create | Full scan | Filtered count |
|---|---|---|---|
| 1,000 | 1,479.6 | 2,905.9 | 331 ms |
| 10,000 | 2,055.8 | 4,004.0 | 160 ms |
| 100,000 | 2,748.0 | 3,561.7 | 204 ms |
Counting costs the same at any size
Counting the records matching a filter took 204 ms and one request against a 100,000-row table, next to 160 ms at 10,000 rows and 331 ms at 1,000. The count runs on the server, so table size barely matters.
Airtable has no count endpoint. Getting the same answer means paging the entire matching set: 501 requests for 50,015 matches, which its 5 req/sec limit stretches to about 100 seconds.
Time to finish a real job
Zite figures are measured. Airtable figures at 10,000 records and above are its theoretical best case — the fastest the job could run given its 5 req/sec limit and 25-record batches, assuming the server answers instantly. A real run would be slower. Each row is scaled to its own longest bar, since the rows are in different units.
Elapsed time to complete
lower is better- Zite, measured
- Airtable, best case
View as table
| Task | Zite | Airtable | Ratio |
|---|---|---|---|
| Import 1,000 records | 0.68 s | 9.25 s | 13.7× |
| Import 10,000 records | 4.9 s | 80 s | 16.4× |
| Import 100,000 records | 36.4 s | 800 s | 22.0× |
| Export 100,000 records | 28.1 s | 200 s | 7.1× |
| Count matches in 100,000 | 0.204 s | 100 s | 490× |
Airtable also meters your API calls
Airtable counts API calls against a monthly workspace quota. Once it is spent, every request slows to 2 req/sec until the month resets. And because its batches are a quarter the size and its pages a twentieth, the same job burns through far more of that allowance.
| Task | Zite | Airtable | Multiple |
|---|---|---|---|
| Import 100,000 records | 1,000 | 4,000 | 4× |
| Export 100,000 records | 50 | 1,000 | 20× |
| Count matches in 100,000 | 1 | 501 | 501× |
A nightly sync can exhaust the plan
An Airtable Team workspace includes 100,000 API calls per month. Re-importing a 100,000-record dataset once a day costs 120,000 calls — over quota before the month is out. Everything after that, including your app’s own traffic, drops to 2 req/sec until the month resets, down from an already tight 5 req/sec.
The same schedule on Zite costs 30,000 calls, and Zite does not meter monthly API volume.
Questions about the Airtable API
Learn more: Airtable API rate limits · Zite database API
How this was measured
The benchmark is a single Python script using only the standard library. It creates a throwaway base on each platform, runs identical operations, and records the latency of every individual HTTP request.
- Identical schema and payloads. Six fields — text, email, number, single-select, long text, checkbox — with deterministic seeded row data, so both platforms received byte-identical content.
- Each platform at its own documented rate limit. Zite at 30 req/sec, Airtable at 5 req/sec, with matched concurrency of 8 across the head-to-head. Running Airtable faster would breach its published terms.
- The 5 req/sec figure is the per-base limit. Airtable also documents 50 req/sec per personal access token, but that covers every base a token can reach, and the 5 req/sec per-base cap still applies underneath. This benchmark uses one base, so 5 req/sec is the limit that applied — running at 50 would have broken it.
- We measured the limits instead of trusting the docs. Batch and page ceilings were probed against the live APIs. Airtable documents a 10-record write batch but accepted 25, and we used 25 — the larger batch makes Airtable faster, so this choice favours it. Using 10 would have understated its throughput by 2.5×.
- Writes parallel, reads sequential — on both sides. Batched writes ran concurrently for each platform. Paging ran sequentially for both, because Airtable's cursor makes it unavoidable. Zite's numeric offsets would allow parallel paging, so its scan figures are conservative.
- Airtable is given the benefit of the doubt. Its figures above 1,000 records are rate-limit ceilings assuming instantaneous server response — the most generous reading possible. Every head-to-head number at 1,000 records is measured on both sides.
- Head-to-head runs were clean. Zero throttling and zero errors on both platforms at 1, 100 and 1,000 records. Latency cells are n = 10; throughput reflects the complete operation.
- The 100,000-record run hit Zite's own limit. It used concurrency 12 and hit 39 rate-limit retries as it saturated 30 req/sec. Those backoff delays are included in the times above, so those Zite numbers are if anything too slow, not too fast.
- Scope. Bulk create, bulk update, single-record read, paged/filtered/sorted queries, full scan, and filtered count. Not an exhaustive survey of either API. Airtable Free's 1,000-record base cap set the head-to-head ceiling.
Run 4 August 2026 · macOS, single client · Zite tables.zite.com/api/v1 · Airtable api.airtable.com/v0
Both platforms tested from the same machine within the same session. Raw per-request logs retained.
Airtable plan quotas, rate limits and post-quota throttling per Airtable's published documentation on API call limits, August 2026.
Try it on your own data
30 requests a second, 100-record writes, 2,000-record pages and no monthly call meter. Import your Airtable base and run the numbers yourself.