Alloy SQLite collections: paginate with limit/offset per fetch, or fetch once and slice in memory?

I'm building an Alloy screen backed by a Backbone collection using the local SQLite adapter. The table will hold several thousand rows, and the target devices have limited RAM, so I need to decide how to bound the query before wiring up data-binding.

As I understand it, the collection's fetch ultimately runs SQL through the adapter, so I can pass limit/offset-style options and re-fetch on each page change. The alternative is one full-table fetch and slicing pages in JavaScript, which gives instant page turns but holds everything in memory. A concern with SQL-side paging is that Alloy's data-binding re-renders bound views on collection change events, so each page fetch may trigger a full re-render unless add/remove granularity is managed. There's also the classic offset-pagination hazard: inserts or deletes between page fetches can skip or duplicate rows unless the sort key is stable.

Assuming a recent Titanium SDK (exact adapter option names seem to vary by version, so I'll confirm against my install):

• For a multi-thousand-row table on mobile, is SQL-side limit/offset pagination the better trade-off over in-memory slicing, and how do I verify the memory difference with Ti.Platform.availableMemory?
• What is the recommended way to keep page boundaries stable when the underlying table changes between fetches?
• Can concurrent fetches with different pagination parameters leave a bound view showing stale or duplicated rows, and how should that be serialized?