Client-side slicing versus server-side fetch for 50k-row table with fixed columns

Goal

Display a 50,000-row dataset in an Ant Design Table while keeping the browser heap under 150 MB and preserving fixed left columns for horizontal scrolling.

Constraints and uncertainty

Client-side pagination with the pagination prop and a full dataSource array is simple to implement, but the entire dataset remains in memory. Server-side pagination via onChange fetches only the current page, reducing memory, yet requires a backend endpoint and controlled current/pageSize state. Virtual scrolling (virtual prop) would minimize DOM nodes but is documented as incompatible with fixed columns, rowSpan, and colSpan, which are required here. The installed Ant Design version is 5.x, where onChange receives (page, pageSize) and a pageSize change typically resets to page 1, but this reset behavior can differ when pagination is fully controlled.

Questions

1. Given the fixed-column requirement that rules out virtual scrolling, does server-side pagination with controlled state remain the only approach that satisfies the 150 MB heap target?
2. If the team adopts server-side pagination, what is the minimal state shape needed to keep current and pageSize in sync with onChange without triggering an extra render loop when the page size changes?