Queryable Mode (Database-Level Data Processing)

Feb 16, 2026
2 minutes to read

Queryable Mode Overview

Queryable mode improves performance when working with large data sets by processing operations like filtering and sorting at the database level rather than loading all data into memory.

When to Use Database-Level Processing

Choose Queryable mode in the following scenarios:

Large data sets : When working with multiple records where performance is critical
Lookup scenarios : For lookup List Views that need to display extensive reference data
Memory-constrained environments : When application memory use needs optimization
Network optimization : When minimizing data transfer between database and application is important

Choose Client mode instead when:

Working with smaller data sets
You need full support for custom properties and complex calculations
Advanced query syntaxes like free joins or upcasting are required

Note

The default data access mode for lookup, root, and nested List Views in ASP.NET Core Blazor applications is Client.

How Database-Level Processing Works

In this mode, the collection source exposes an IQueryable<T> query shaped according to List View settings. The List Editor does not load all objects immediately. Instead, the editor control extends the query to load only objects visible in the control, then iterates the query to load objects from the database.

Database-level processing is automatically enabled for lookup List Views when the corresponding List View node in the Application Model specifies any data access mode other than Client.

Supported editors:

LookupPropertyEditor
DxTreeListEditor (ASP.NET Core Blazor)

Limitations and Considerations

When using database-level processing, be aware of these limitations:

Custom Properties Not Supported

Custom persistent properties (IModelMember.IsCalculated = false) created in the Model Editor and CustomizeTypesInfo method are not displayed
Custom properties added at runtime
Non-persistent properties without PersistentAlias decoration (XPO)
Non-persistent properties in EF Core

Query Limitations

Filter, sort, and group operations do not work with unsupported properties listed above
Advanced query syntaxes are not supported:

Database Compatibility

Legacy databases with compound primary keys are not supported

Collection Behavior Changes

Queryable collection sources create new collections from queries instead of using original collections
Custom logic in original collection getters and event handlers is not executed
All properties are calculated on-demand based on visibility and rule requirements