Fusion Tables shutdown leaves OFFSET pagination of large filtered queries unspecified

The short answer

On both unresolved points, the archived documentation supports a conservative reading: no, deterministic paging under concurrent edits was never guaranteed, and no, the per-query result cap did not make deep OFFSET pages unreachable — the cap bounded the returned page, not the addressable range. The first conclusion rests on what the docs never said; the second on how LIMIT, OFFSET, and the response cap were documented to compose.

Stability across concurrent edits: not guaranteed

Fusion Tables exposed a SQL-like SELECT with LIMIT and OFFSET as the only paging mechanism. No cursor, keyset token, or snapshot handle was ever documented. That absence is itself the answer to your first question: each page fetch was an independent query against live data, with no documented transactional or snapshot isolation. Rows inserted, updated, or deleted between fetches could shift OFFSET positions, producing skipped or duplicated rows in the client's reconstructed result set.

There is a second, quieter caveat: even without concurrent edits, OFFSET paging is only well-defined over a stable ordering. The documentation did not promise a deterministic default row order, so a migration document should treat ORDER BY on a unique column (or rowid) as a prerequisite for meaningful paging, not an optional refinement.

The per-query cap: it bounded the page, not the range

The API enforced server-side caps on rows returned per response, documented as varying by access level (authenticated versus unauthenticated). The cap applied to the rows in an individual response — effectively a ceiling on LIMIT — not to the total rows a client could reach across successive queries. Because OFFSET was evaluated per query before the response was assembled, a request with OFFSET 50000 LIMIT 500 was legitimate as long as 500 was within the per-response maximum. There is no documented global ceiling on OFFSET itself.

One honest uncertainty: absence of a documented OFFSET ceiling is not proof none existed in practice. Undocumented behavior may have differed from the documented contract, and with the service shut down since December 2019 this cannot be tested against a live endpoint. If your migration design depends on very deep paging having worked, flag that assumption for review rather than asserting it.

How to describe it in a migration document

A defensible characterization is: Fusion Tables paging was best-effort OFFSET paging over independently executed queries. Correctness under concurrent modification was a client-side concern, addressed by:

• Ordering by a unique key (ORDER BY rowid) so page boundaries were at least well-defined per query.
• Deduplicating by rowid on the client to absorb overlaps caused by shifting offsets.
• Keeping LIMIT within the per-response cap for the relevant access level, and treating the cap as a page-size limit rather than a result-set limit.

For verification, check the Internet Archive captures of the Fusion Tables query-language documentation (the LIMIT/OFFSET and response-size sections), the 2013 deprecation and December 2019 shutdown notices for any late documentation revisions, and archived Stack Overflow or user-group threads reporting duplicate or skipped rows during OFFSET paging — such reports would corroborate the lack of snapshot isolation that the documentation's silence implies.