Repository source: docs/plans/archive/sqlite_download_with_query_webui_pagination_step1_solution_assessment.md
SQLite Viewer Pagination Step 1 Solution Assessment
Problem Statement
The SQLite viewer currently shows only bounded result previews, so users need a way to move through larger table and query-result datasets without loading or displaying everything at once.
Option A: Database-level page navigation
Use the browser-resident SQLite database to retrieve one page at a time for both table previews and user-selected queries, with previous/next controls and a visible page position.
Pros:
Supports datasets larger than the current display cap.
Preserves the existing client-side, read-only execution model.
Works for arbitrary read-only queries and table views without server changes.
Keeps browser memory and DOM work bounded.
Cons:
Offset-based navigation can become slower on very large result sets.
Exact total-page counts require an additional count operation and may be expensive for complex queries.
Sort changes must reset the current page to keep navigation understandable.
Option B: Fetch once, paginate in JavaScript
Fetch a larger bounded result set once, then divide the received rows into client-side pages.
Pros:
Simple navigation after the initial query.
No repeated database execution while changing pages.
Exact page counts are trivial for the fetched subset.
Cons:
Does not provide access beyond the fetch cap.
Can use substantial memory and make initial loads slow.
Gives the appearance of pagination without solving large-result exploration.
Option C: Keyset/cursor pagination
Navigate with a cursor based on the selected ordering rather than a page offset.
Pros:
More efficient for deep navigation over large ordered datasets.
Avoids repeatedly scanning skipped rows.
Cons:
Requires a reliable, unique ordering for every table and arbitrary query.
Hard to support consistently with editable user SQL and changing sort choices.
Adds more complex state and weaker “go to page” behavior.
Recommendation
Recommend Option A, initially with bounded page sizes, previous/next controls, and page position indicators for both table data and query results. It fits the existing local SQLite architecture, solves the current cap limitation, and leaves room to add exact counts or cursor optimization later if real datasets require them.