>> directly on the Postgres DB and from Qlik replicate Postgress DB source,
Sounds like the task is replicating from Postgres source to Postgres target, please confirm. Is the first the DB source and the second target? or is there a whole other target?
Please clarify what you believe the differences to with pictures if you have to with column/rows text output best you can. I suspect this is to do with NULL vs EMPTY STRING (zero length) or even single space string.
Whilst it is not unreasonable to expect that going from one DB type to the same DB type everything would stays exactly the same, that's not how Replicate work. Replicate is ready to deal with dozens od niput DB's and also dozens of output DB types. It does NOT special case equal types. It normalizes (well documented in the userguide) source DB metadata types to 'Replicate datatypes' and then maps those Replicate datatypes on tthe seemingly most suitable target metadatatype. Sometimes stuff (decimal precision) get's lost in translation. Sometimes you can fix that with transformations or pre-created target tables.
NULL vs EMPTY STRING vs SINGLE SPACE actions are sometimes DB dependent, and sometimes Replicates is/was used to 'clean' design/filter data-entry 'sloppy-ness' on source.
For several sources/targets Replicate has internal parameters for control this some. For example for Snowflake target it has "emptyFieldAsNull". I do not see such parameter from Postgres.
You might want to run a small test and use the internal parameter "keepCSVFiles" to figure out more clearly where in the replication process the issue you observed end-to-end might be happening.
Sometimes a transformation with 'ifnull' or 'length' or 'rtrim' can help mitigate the discrepancies.
