The limit you find out about on a Friday
Every platform publishes its limits, and most of them publish honestly. Airtable's rate limit page says 5 requests per second per base, and that is exactly what you get. The number is not usually what hurts. What hurts is the Friday afternoon when traffic runs three times normal, a sync job starts collecting 429s, and you have no way to tell whether you crossed a documented line or an undocumented one.
The published number is the easy part
Airtable's web API allows 5 requests per second per base, plus 50 requests per second across all traffic from a single personal access token or service account. Cross either and you get a 429, then you wait 30 seconds before anything succeeds again. That is all documented, and the official JavaScript client ships with backoff and retry built in. You can design around it.
The sentence sitting under those numbers is the one worth reading twice. Airtable says it "may change the enforced API rate limits or enforce additional types of limits in our sole discretion, including tiered based on pricing plan." That is reasonable contract language for a hosted service. It also means the figure you built your sync around is a current value rather than a guarantee, and no test in your repo will fail the morning it changes.
The 30 second penalty is the part that catches teams out. A per-second cap is a throughput problem, and a queue fixes throughput problems. A half minute lockout turns a brief burst into a backlog, and a backlog into a retry storm if your automation does not know to stand down. I have watched an hourly sync quietly fall 40 minutes behind for a week because nobody was watching the 429 count.
One number, and two days of history
Bubble moved from capacity to workload units in April 2023, and their own documentation is candid about why. Under the old model apps slowed down when they crossed the capacity limit, throttled, in Bubble's words, "right when they most needed to keep up with increased demand from end-users." Workload units are a better model than that, and saying so in your own manual takes some nerve.
The current plans put 50,000 workload units a month on Free and 175,000 on Starter, which costs $29 a month billed annually. Starter also gives you 2 days of server logs. Those two facts interact in a way the pricing page does not spell out: when your workload spikes, Bubble tells you to investigate with app metrics and the server logs, and on Starter your forensic window is 48 hours. A spike that begins on Friday night is unreadable by Monday afternoon.
There is a second interaction further down. Bubble states that Free and Agency plans cannot subscribe to workload tiers and cannot enable overages, because those plans are built for development. That is a defensible rule. It also means the ceiling on those plans is not a bill, it is a stop, and plenty of prototypes become the business without ever changing plan.
What a limit looks like when you own the runtime
Custom infrastructure does not escape limits. Cloudflare Workers caps memory at 128 MB per isolate, allows 100,000 requests a day on the free plan, and holds Worker startup time to one second. The page listing all of it was last updated on 12 October 2026, and it is longer than Airtable's.
The difference shows up in what you can do about it. The paid CPU limit defaults to 30 seconds, and you raise it to the 5 minute maximum by writing cpu_ms into your Wrangler config. The subrequest limit per invocation is 10,000, also configurable. When you blow through one, Cloudflare returns Error 1102, the invocation shows up as exceededCpu in your trace events and Logpush, and you can reproduce the whole thing locally with the DevTools CPU profiler. The failure has a name, a telemetry field and a local repro.
Even the free daily request cap comes with a decision attached. You choose per route whether exceeding it fails open, bypassing the Worker entirely, or fails closed and returns a 1027 error page. For a security-critical Worker you want closed. For a marketing page you want open. That choice belongs to whoever owns the product, and on a hosted platform it is made for you. When we moved Stay World Class from Webflow and Xano onto Next.js, NestJS and Supabase, the measurable win was Lighthouse going from 55.91 to 91 and LCP dropping 77%, but the quieter win was that every remaining bottleneck became something we could open and read.
When the platform's limit is the right limit
If your traffic is bounded and you know the bound, none of this applies to you. An internal Airtable base serving 30 people will never see 5 requests per second, and no amount of engineering makes that number more comfortable than it already is. The ceiling only matters once you are near it.
If nobody on your team wants to carry a pager, a vendor absorbing the operational surface is worth real money, and more than most teams admit. Somebody is going to handle the TLS renewal and the 3am failover. Paying Bubble or Airtable to be that somebody is a legitimate trade, not a failure of ambition.
The signal to move is narrower than the sales pitch suggests. It is not a bad month or an annoying limit. It is the point where you start designing around the ceiling instead of inside it: batching writes to dodge a rate limit, splitting a base because one grew too large, adding a cache to hide a response time you cannot fix. When the workaround has its own workaround, the platform has stopped saving you time. Until then it is still doing the job you hired it for.
