That the table is completely refreshed everyday doesn't mandatory mean that no incremental approaches are possible - especially if some essential parts like adding a creation/change timestamp to the records is possible within the database. Another option might be not to load the entire table in one run else to slice it within appropriate loops against period- or category-information or whatever is possible.
Further thinkable is not to load this table - probably a view of the transformation from n other tables - else going more directly to the sources.
Beside this the observed slowdown should not be caused from Qlik else rather from the database or the driver or the network which restrict the performance - more or less intentionally by any settings and/or by any caching-logic. You may also take a look on the RAM consumption of the Qlik server because if the system is forced to swap any data to the virtual RAM the performance will usually drop significantly - where jus 2 M of records should have such impact - unless the system is already near the max. workload.
