No-code performance and scale

A no-code app is ready for wider use when essential tasks stay usable and return complete, correct results at expected data volume and user load. Measure those tasks, locate the delay, check configured platform limits and repeat after each change.

Define what growth means

Record count, simultaneous users and background work can grow at different rates. An employee who sees only their own requests may need a much smaller working set than a manager searching the full history.

For each essential task, record expected total records, records available to one user, likely concurrent use and required outcome. Include files, calculations and connected actions when they affect the task.

Agree an acceptable response time for the people doing the work. A quick search that omits an eligible record has failed regardless of its speed.

Find where the wait occurs

Follow a task from opening the app to seeing its result. Separate app startup, sync, list loading, a save and a connected service’s response. Record the app version, account, device, network and data volume so a later observation is comparable.

Choose diagnostics that suit the builder and your plan, following the product’s current documentation. Power Apps Live monitor shows data operations, network calls, errors and timing. Match each diagnostic observation to the task the user performed.

For Bubble, database searches can affect workload and responsiveness; see the supporting article on searches for detailed diagnosis.

For Power Apps canvas apps, Live monitor can be paired with Trace records in behaviour formulas. Trace can capture context such as the active screen, the user, the environment, row counts and elapsed times, helping distinguish a general delay from one associated with a particular user or app state.

Account for structural overhead

Data growth is not the only source of delay. In Power Apps canvas apps, a screen that refers to controls or data on another screen can make both screens load and evaluate, increasing processing and memory use even when the user opens only one of them.

Power Apps Studio’s App Checker can flag cross-screen references in its performance section under “Inefficient Delay Loading”. These references can also make the app harder to maintain and debug, so consider whether the data flow can be separated more clearly in a redesign.

Protect result completeness

A speed change can alter which records are retrieved. Check both speed and completeness after each change.

In a Power Apps canvas app, a nondelegable query processes an initial 500 records by default, configurable up to 2,000. It can return an incomplete answer when the source is larger. Check the formula and connector’s delegation support, then search for a known eligible record outside the locally processed set.

Delegation depends on what the data source supports: Dataverse, for example, supports the Power Fx “in” operator, while Excel does not. If any part of a Power Apps query cannot be delegated, the app processes the query locally rather than delegating only the unsupported part.

Delegation Support Across Data Sources in Power Apps

Check the actual limits

List the builder, plan, data source and connectors that will be used. Record the relevant storage, request, automation and usage rules, as well as the amount of data delivered to each user. These are different constraints: a query limit can hide a result while storage remains available.

Check the organisation’s actual entitlement and current terms before rollout. Confirm which limits apply to the configured data source and connectors rather than assuming every limit has the same effect.

Change one cause and check again

Narrow an initial list, remove a confirmed repeated lookup or move a suitable filter closer to the source. Keep access rules and the expected result intact. Repeat the task with comparable records and an ordinary account; record both elapsed time and whether the right record or write appeared.

If an essential task remains too slow or incomplete, decide whether to redesign the data path, change the platform or investigate a narrow coded operation. Base that choice on the observed gap and the team’s ability to maintain the result.

When a delay appears only in a particular environment or for certain users, record that context alongside the elapsed time rather than treating one observation as representative.