The query uses a row limiting operation without OrderBy warning in EF Core pagination

Context

When paginating large datasets in EF Core, the framework emits a warning — "The query uses a row limiting operation (Skip/Take) without OrderBy which may lead to unpredictable results" — whenever Skip or Take is applied without an explicit ordering clause. This warning signals a correctness risk, yet it does not prevent execution.

Core Decision

The core decision is whether to adopt offset-based pagination (Skip/Take) with mandatory OrderBy, accepting linear performance degradation as page depth increases, or to implement keyset pagination manually using a Where predicate on the last-seen key. Keyset pagination avoids the scan-and-discard cost but requires a unique, immutable, sequentially ordered column and careful handling of composite keys. EF Core 8's AsSplitQuery improves include-heavy queries but still generates OFFSET/FETCH for Skip/Take. Client-side evaluation before paging triggers OutOfMemoryException on large result sets, a documented failure mode.

Open Questions

1. What criteria should determine the choice between offset and keyset pagination when the dataset exceeds 100,000 rows and the ordering column is a non-sequential GUID?
2. How can composite-key entities be safely paginated using keyset logic without introducing ordering instability?
3. Does the warning behavior differ between EF Core 7, 8, and 9 in a way that affects production logging strategies?