A low-code app can feel instant with a small test table and then slow down—or return incomplete results—when customer data grows. The key issue is not a universal row-count limit: it is whether the app sends filtering and other supported work to its data source, and retrieves only the rows and columns it needs.
Why a larger table exposes problems
A prototype often works with a small sample because even inefficient queries have little data to process. A real customer table changes the workload: a formula may no longer be executed by the data source, the app may retrieve more data than the screen needs, or paging may not suit the way users browse results.
As an Amazon Associate I earn from qualifying purchases.
Those are different problems. A table can store many records while an app handles them well; conversely, a query can behave incorrectly or feel slow well before storage capacity is the issue. Microsoft’s Power Apps guidance emphasizes whether a Power Fx query can be translated into a query that its connected data source supports. Microsoft Learn: Understand delegation in a canvas app.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Delegation determines where the query runs
When a query is fully delegable, Power Apps passes the supported work—such as filtering—to the data source, which processes the records and returns results. When any part of a query is nondelegable, Power Apps retrieves a limited set of records and performs that work locally. Whether a particular formula delegates depends on the functions used and the connected data source or connector.
#1 Best Overall
This can turn a performance concern into a correctness concern. Microsoft says the default local data row limit is 500 records, configurable up to 2,000. That limit applies to nondelegable processing; it is not a maximum size for the stored table. If a matching record is outside the set retrieved for a nondelegable query, the app may fail to find it even though it exists in the full table.
Increasing the setting can expose more records to local processing, but it does not make a query delegable. Microsoft cautions that larger result sets can affect app performance, particularly with wide tables, and recommends delegating as much work as possible. Microsoft Learn’s delegation guidance describes the local limit and its trade-offs.
Retrieve a small payload, not the whole table
Even a delegable query can send too much data if the app asks for broad results or unnecessary columns. Design the screen so the source applies supported filters and the app retrieves the fields needed for the current interaction. This reduces the amount of data crossing the connection and the work the app must handle.
Microsoft’s guidance on small data payloads notes that gallery and table controls bound directly to a remote data source can page results in small increments—for example, 100 records—rather than requiring the app to load the entire data set at once. The 100-record figure is an example, not a guarantee that every app, connector, or screen will use that exact page size or perform equally well. Microsoft Learn: Small data payloads.
Dataverse paging is separate from the canvas app row limit
For Dataverse, distinguish the canvas app’s local limit for nondelegable queries from the paging rules used when a Dataverse query returns results. Microsoft documents QueryExpression page sizes of up to 5,000 rows for standard tables and 500 rows for elastic tables. These are page-size limits, not maximum table capacities.
Microsoft recommends paging cookies for data sets of all sizes. Simple paging is intended only for small data sets: it has a 50,000-record total ceiling and becomes less efficient as the result set grows. The paging mechanism should be chosen and implemented for the query and table type, rather than treated as a fix for a nondelegable canvas-app formula. See Microsoft Learn: Page results using QueryExpression.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose table behavior for the workload
Microsoft describes Dataverse elastic tables as an option for workloads that need high-volume data handling and scalable throughput. They are not an automatic remedy for a slow app: the query still needs a suitable retrieval pattern, and Dataverse throttling limits still apply. Whether a standard or elastic table fits depends on the workload and its access patterns. Microsoft Learn: Create and edit elastic tables.
Quick Recap
Diagnose the customer’s actual screen
- Check the query first. Inspect the Power Fx formulas used by the affected screen and determine whether every operation is supported for the app’s connector and data source. A nondelegable part can limit processing to the local row set.
- Check for incomplete results. Test a record known to exist beyond the local limit. If the app misses it, investigate delegation before treating the issue as a storage-capacity problem.
- Reduce what the screen requests. Filter at the source where supported, return only needed columns, and use controls that retrieve results as users browse rather than loading a broad table up front.
- Review paging when using Dataverse queries. Confirm the table type and use the documented paging approach; do not confuse QueryExpression page sizes with the canvas app’s nondelegable row limit.
- Measure the real workload. Observe the customer’s own queries and screen behavior with representative data. The Microsoft guidance explains the mechanisms, but it does not establish a record count at which every app becomes slow.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
