A few decades ago, I was faced with the same problem with two RDB databases. At the time, RDB was a DEC product. It's somewhat like Oracle RDBMS. My case was a little different from yours. In my case, both databases were production, under separate management.
What I did was to generate a third database, which I called a "metadatabase". Its function was to store data definitions from the two target databases in user tables. Each user table class had two tables, one for each of the two target databases.
There was a pair of tables for table names, and a pair for column names.
What I then managed to do was construct queries that used the SELECT... INSERT... construct to retrieve data definitions from the system tables of one of the target databases and insert the same data into one of the paired user tables in the metadatabase. This obtained hundreds of tables and thousands of columns. The column data included the type and precision of the data stored in the column.
I then constructed queries that would locate tables that were in one database but not the other, columns that were in one database but not the other, and columns that were in both databases but with different datatypes or different precisions.
I was then able to resolve the discrepancies one by one by conversations with the two dbas. The most interesting case was a table that was defined as integer in one database, but floating point in the other. This had been the root cause of mysterious anomalies that had eluded analysis for years.
I'm sorry this description is so generic, but DEC RDB and Postgres are very different anyway, so you will be faced with different challenges that I was if you opt for this approach. You may end up having to dump metadata into flat files for staging purposes.
