Every Glide app starts fast. Then the data grows, the app gets sluggish, and you hit the wall: Glide Tables are capped at 25,000 rows total — across every table in the app. This is the single most common scaling question we get, and the fix is almost always architectural, not a setting you flip.
The 25,000-row limit isn't a bug to work around — it's a signal that your data belongs in a different storage tier. Treat it as an architecture decision, not a ceiling.
Why the limit exists
Glide processes data client-side. When your app loads, it pulls rows into the browser and runs computed columns, filters, and relations locally. That's what makes Glide feel instant — and also why unbounded row counts eventually choke the device. The 25,000-row cap protects that performance model.
Step 1: Separate hot data from cold data
Most apps don't need every row live at once. Split your data by access pattern:
- Hot data — records users touch this week (active orders, open tickets)
- Cold data — historical records kept for reporting or audit
Hot data stays in Glide Tables. Cold data moves to a Big Table or an external source you query on demand.
Step 2: Move volume to Big Tables
Glide Big Tables scale to 10 million rows with server-side queries and API access. The tradeoff: some computed-column types don't run on Big Tables, so you push that logic upstream.
// Before: a Glide computed column doing the math client-side
// total = rollup(lineItems, 'amount', 'sum')
// After: compute on write, store the scalar in a Big Table column
const total = lineItems.reduce((sum, item) => sum + item.amount, 0)
await big.orders.update(orderId, { total })Step 3: Choose the right backend tier
Here's the decision matrix we use on every engagement:
| Data volume | Storage tier | Notes |
|---|---|---|
| < 25,000 rows | Glide Tables | Full computed-column support, fastest |
| 25K – 10M rows | Big Tables | Server queries, limited computed columns |
| > 10M rows | External (BigQuery, SQL) | Query via API; Glide renders results |
Step 4: Index your query columns
Whether you land on Big Tables or an external SQL source, the filters users hit most should be indexed. An unindexed filter over millions of rows is the thing that actually feels slow — not Glide itself.
How many rows can a Glide app really handle?
With Big Tables, a single app comfortably handles millions of rows because queries run server-side and only matching rows return to the client. The practical limit becomes your query design, not the row count.
Will moving to Big Tables break my computed columns?
Some will. Rollups, lookups, and a few math column types behave differently on Big Tables. We migrate that logic to compute-on-write or to the external source so the client only renders finished values.
Is the 25,000-row limit per table or per app?
Per app. It's the total across every Glide Table combined — which is exactly why splitting hot and cold data is the first move.
The bottom line
Scaling Glide is a storage-tier problem, not a platform ceiling. Keep hot data in Glide Tables, push volume to Big Tables, and reach for an external source only when you genuinely cross 10 million rows. Architect it once and the app stays fast as the data grows.
