I tried reverse engineering a Postgres 11 database, but it fails with an error during the selection of the objects to be retrieved: "column p.proisagg" does not exist. Which makes sense as that column was removed in Postgres 11 and replaced with the column "prokind" which was necessary to support the new stored procedures.
My current workaround is to disable the reverse engineering of functions in the definition of the connection because the "Reverse Engineering Wizard" will fail to load at all (no tables, no views) if loading of the functions/procedures fails.