What's actually happening

An app built when a form held 500 records makes reasonable assumptions: fetch everything, loop through it, show every column. Those assumptions don't hold at 50,000. The fix is nearly always days of work, not a rebuild — but you have to know which of four things is biting.

01 · The Deluge statement limit

Deluge caps how many statements a function can run in one pass — somewhere between 5,000 and 50,000 depending on your plan — and every trip through a loop eats into that budget. A routine that handled 500 records without complaint can run dry well before it reaches 50,000. This is the textbook "worked in testing, failed in production" case, and by far the most common cause.

02 · How you query

Zoho's criteria guidance is blunt: filter on mandatory or unique fields like ID or email if you want fast fetches, and remember that OR conditions cost more than AND because each one is evaluated separately. The docs also flag that pulling all records at once creates load and drags performance down. Fetch narrow, fetch on indexed fields, and never pull the whole set when you only need a slice.

03 · Forms talking to the server constantly

On-load scripts, on-user-input actions, formula fields and lookup filters that reference another field all count as workflow action calls — and those are throttled at around 100 per minute per IP. That budget is shared, so a whole team behind one office connection is drawing on it together. A form that felt instant for one tester can stall when eight people hit it at once.

04 · Reports asked to render too much

Creator publishes a few thresholds worth knowing. A report won't load if a subform or multi-select lookup in quick view has more than 2,500 values mapped to one record. A form with 30 or more multi-select and checkbox fields is documented as slower to fetch. Both of those you can undo — but one you can't, so plan around it.

Slowdowns at scale are usually a design signal, not a platform limit — and most are fixable without a rebuild. The short version

Creator already has an answer

Zoho's recommendation for high-volume work is Batch Workflows, and they exist for exactly this. They chew through records in configurable batches — 10, 50, 100, 200, 500 or 1,000 — with each batch running as its own asynchronous flow. The docs state the reason plainly: splitting the dataset this way gets you around Deluge's execution limits and keeps things running smoothly.

For work that doesn't need to happen while someone waits, Schedules move it off the critical path completely. The record gets flagged on save, and the heavy lifting runs later — so the user isn't left staring at a spinner while a loop grinds through thousands of rows.

// The anti-pattern: a scheduled/standalone function that loops the whole set.
// Each iteration spends statements — cross the plan limit and it fails mid-run.
pending = Orders[Status == "Pending"];   // pulls everything
for each rec in pending
{
    // ...per-record work...
}

// The fix isn't more Deluge — it's a Batch Workflow (configured in the
// builder) that runs the same logic across batches of, say, 200 records,
// each batch as its own async flow. For non-urgent work, flag on save
// and let a Schedule process it off the critical path.

What to actually spend

Three tiers cover nearly every case. Match the tier to the symptom — most apps at this stage need one focused optimization pass, not a rewrite.

The cheapest lever is also the one most teams have never heard of. Zoho can index fields for you on the back end — their Best Practices docs say indexed fields in criteria help fetch relevant records faster, and point you to support to have it enabled. It isn't self-service, but asking costs nothing. Work out which fields your app filters on most and raise a ticket before you commit to anything bigger.