NSFetchRequest pagination and fetchBatchSize interaction

Direct Answer

fetchBatchSize reduces the memory footprint of the window defined by fetchLimit because batching operates on the windowed result set (after LIMIT/OFFSET), not on the full table. fetchBatchSize does not alter the generated SQL — fetchLimit and fetchOffset map directly to LIMIT and OFFSET clauses, while fetchBatchSize only controls how many managed objects are materialized per round-trip when you iterate the returned array.

How the Properties Interact

1. SQL generation: Core Data emits SELECT ... LIMIT ? OFFSET ? using fetchLimit and fetchOffset. The fetchBatchSize value never appears in the SQL statement.
2. Result materialization: The fetch returns an NSArray of NSManagedObject faults. When you enumerate this array, Core Data fires faults in batches of size fetchBatchSize (default 0 = fetch all at once).
3. Memory profile: With fetchBatchSize = 0, iterating a fetchLimit = 1000 request materializes all 1,000 objects simultaneously. With fetchBatchSize = 50, peak memory stays proportional to ~50 objects because each batch is faulted, used, and released before the next batch loads.

Practical Implications

• Memory savings only apply during iteration. Holding the NSArray without enumerating keeps all faults in memory; the batch size has no effect until you walk the array.
• Large offsets remain slow. SQLite must scan skipped rows for OFFSET; fetchBatchSize does not mitigate this. For deep paging, prefer keyset pagination (WHERE pk > lastSeen ORDER BY pk LIMIT N).
• Relationship prefetching may ignore batch size. If you set relationshipKeyPathsForPrefetching, Core Data may load related objects in a single batch regardless of fetchBatchSize.
• Behavior is stable. Identical in Objective-C and Swift since iOS 3.0 / macOS 10.4.

Verification Steps

# 1. Observe SQL (no batch size in output)
# Launch app with:
-com.apple.CoreData.SQLDebug 1

# 2. Compare peak memory in Instruments → Allocations
# Fetch limit=1000, batchSize=0 vs batchSize=50 while enumerating

# 3. Confirm batch faulting
-com.apple.CoreData.Logging.stderr 1
# Log shows fault firing in groups matching fetchBatchSize

One Diagnostic Detail

Are you enumerating the fetched array in a single pass, or retaining it for random access? Random access defeats batch faulting because Core Data must keep the entire window materialized to satisfy arbitrary index lookups.