PageNumberPagination or CursorPagination when rows shift during a zero-downtime backfill

A small DRF service requires a pagination change applied without downtime while a backfill concurrently inserts or updates rows. The current endpoint uses PageNumberPagination, which exposes page and page_size parameters and returns a total count, but translates page numbers into OFFSET/LIMIT so a page's contents can shift between requests. CursorPagination avoids OFFSET drift by encoding ordering values into an opaque cursor, yet it does not return a total count by default and exposes only the cursor parameter. It also requires a unique, indexed ordering field—commonly the primary key—because it does not automatically append a tiebreaker to non-unique columns.

The unresolved decision is whether keyset stability justifies breaking the client contract: clients that jump to arbitrary page numbers or display total counts will break, and supporting both pagination styles during a transition adds complexity. Version-sensitive defaults such as page_size, max_page_size, cursor payload, and count presence must be confirmed against the installed DRF release rather than assumed.

Which documented approach minimizes silent data shifts for clients that only page forward, and what is the least disruptive way to expose the new ordering without forcing an immediate client migration? Should the transition keep the old paginator on the existing viewset and introduce the new ordering through a separate endpoint or query parameter until clients have migrated? How can the ordering field be made unique and indexed without extending the downtime window?