Phalcon paginator limits: QueryBuilder deep offsets versus NativeArray memory on large tables

I'm designing the pagination layer for a Phalcon application where one table is expected to grow into the millions of rows. The documented Phalcon\Paginator adapters appear to offer two very different trade-offs, and I want to pick the right one before the data volume makes the choice expensive to reverse.

From what I understand, the QueryBuilder and Model adapters translate pagination into SQL LIMIT/OFFSET, so requesting page 5,000 would issue a large offset and inherit the database's deep-offset performance cost. The NativeArray adapter, by contrast, paginates an array already loaded into memory, which seems to make it unsuitable for anything beyond small datasets.

My constraints: the UI needs classic numbered-page navigation (so a pure keyset/cursor approach would require extra design work), and the extension version in production may differ from my dev machine, so adapter namespaces are a concern too.

Does the QueryBuilder paginator do anything beyond plain LIMIT/OFFSET to mitigate deep-offset degradation, or is that entirely on the database? At roughly what dataset size does NativeArray become a practical memory problem? And is there a documented way to combine the paginator's total-pages metadata with keyset-style fetching?