pgAdmin ER Diagrams Compared With a Modelling Tool: What the ERD Misses and Why

You generated an ERD for your database in pgAdmin, and half the tables float on the canvas with no line to anything, although the application joins them every day. pgAdmin's ERD draws exactly the foreign keys PostgreSQL declares, and nothing else. DbSchema reverse-engineers the same database for free, lets you add the missing relationships as virtual foreign keys in its model without changing the database, and keeps that model when the schema outgrows one canvas or one engine.

pgAdmin 4's ERD tool draws the foreign keys PostgreSQL declares

pgAdmin is the PostgreSQL management tool, open source under the PostgreSQL licence, and runs as a desktop application or in server mode; its site lists version 9.19, released on 29 October 2026. Its ERD tool generates a diagram from a database, a schema or a table. ERD for database "will fetch all the tables from all the schemas of the database", and ERD for table fetches "all the tables linked directly or indirectly" to the table you picked, as pgAdmin's ERD tool documentation describes.

On the canvas, the toolbar adds tables, one-to-many relationships and many-to-many relationships, where the many-to-many option creates a new table for the two related tables. You can add notes to table nodes, auto-align the layout, hide column details, save the diagram to a file and reopen it, download it as an image, and Generate SQL writes the DDL for the diagram, optionally with DROP TABLE statements.

For a schema that declares its keys and fits on one canvas, that covers the picture. The gaps start where the catalog has nothing to say.

An undeclared relationship leaves a table unconnected and unprotected

A diagram generated from PostgreSQL draws one line per FOREIGN KEY constraint in the catalog (PostgreSQL constraints). These three tables hold two relationships, but only one is declared:

CREATE TABLE customers (customer_id INT PRIMARY KEY, name TEXT NOT NULL);
CREATE TABLE orders (order_id INT PRIMARY KEY,
  customer_id INT NOT NULL REFERENCES customers (customer_id));
CREATE TABLE order_notes (note_id INT PRIMARY KEY, order_id INT NOT NULL, note TEXT NOT NULL);

The catalog holds the declared one and nothing else:

SELECT conrelid::regclass AS table_name, confrelid::regclass AS references_table, conname
FROM pg_constraint WHERE contype = 'f';

So order_notes lands on the diagram as an island. The missing constraint is not cosmetic either: PostgreSQL refuses an order for customer 5, who doesn't exist, with violates foreign key constraint "orders_customer_id_fkey", but it accepts a note for order 99, which doesn't exist either:

INSERT INTO order_notes VALUES (100, 99, 'ship Friday');
SELECT n.note_id, n.order_id, o.order_id IS NULL AS orphan
FROM order_notes n LEFT JOIN orders o ON o.order_id = n.order_id;

Older schemas often leave keys undeclared, and the joins live in application code. There, the generated diagram is a picture of the constraints rather than of the data model, and you need somewhere to record the relationships the database does not know.

A modelling tool keeps a design model beside the database

DbSchema Community Edition connects to the same PostgreSQL database and reverse-engineers it into an interactive diagram, free for any use and with no time limit. The step-by-step is in create an ER diagram for PostgreSQL.

The difference from pgAdmin is where the result lives. pgAdmin saves a diagram file that you reopen in pgAdmin. DbSchema reverse-engineers the schema into a design model, and the diagrams are views of that model; DbSchema Pro saves it as one .dbs file that holds the tables, foreign keys and diagrams (DbSchema and Git).

Virtual foreign keys draw the missing line without changing the database

A virtual foreign key exists only in the DbSchema model, and DbSchema never creates it in the database. You drag the child column onto the parent column, as for a real foreign key, and tick Virtual in the dialog (foreign keys). For order_notes, that draws the missing line without an ALTER TABLE on a schema you may not be allowed to change, and in DbSchema Pro the Query Builder and the Data Explorer follow virtual foreign keys like real ones. Keeping a virtual foreign key means saving the model file, which is Pro too.

Layouts work differently too. One DbSchema model holds as many diagrams as you need, each with the tables of one part of the application, and moving or grouping tables changes only the model. That keeps a schema of hundreds of tables readable as one view per subsystem.

DbSchema adds other engines, documentation and a model comparison

pgAdmin is built for PostgreSQL. When a MySQL database or a MongoDB collection joins the project, DbSchema reverse-engineers it in the same tool, with the same diagrams, and every engine is in the free Community Edition.

DbSchema Pro writes the model as an HTML5 page, a PDF or Markdown (schema documentation). The HTML5 page carries the diagram as an SVG image, sharp at any zoom, with table and column comments as mouse-over tooltips, for a reviewer who has no database access.

pgAdmin's Schema Diff, according to its documentation, compares objects "between two databases or two schemas" and generates synchronization scripts. DbSchema Pro compares the design model with the database, lists every difference, and lets you choose per difference whether the model or the database changes, or generate the SQL script to review first (schema synchronization). The first compares two live sides; the second checks the database against the agreed design.

Both start free, and DbSchema Pro adds the saved model

The diagram

The row that decides most cases is the relationships the catalog lacks:

What leaves the tool

Documentation and comparison are where DbSchema Pro starts:

DbSchema prices come from the purchase page, and a new installation runs every Pro feature for 15 days.

One catalog query tells you whether the ERD is enough

Run the pg_constraint query above on your own database. If every relationship the application uses is in the result, pgAdmin's ERD draws the whole picture. If tables you know are related are missing from it, or the project spans more than PostgreSQL, or the diagram has to be kept, shared and checked against production, that is the work DbSchema does.

To see your own schema that way, download DbSchema, connect it to the PostgreSQL database you manage in pgAdmin and reverse-engineer it: the Community Edition draws the diagram for free. Saving the model with its virtual foreign keys, generating documentation and comparing the model with the database are in DbSchema Pro.

Frequently asked questions

Does pgAdmin have an ER diagram tool?

pgAdmin 4 has an ERD tool that generates a diagram for a database, a schema or a table, and lets you add tables, one-to-many and many-to-many relationships and notes on a canvas.

How do I generate an ER diagram from an existing database in pgAdmin 4?

Right-click the database and choose ERD for database, which fetches all tables from all its schemas. ERD for table on a table fetches every table linked to it directly or indirectly.

Can pgAdmin export an ER diagram?

The Download image button saves the diagram as an image, Generate SQL writes its DDL, and Save as stores the diagram in a file you reopen in pgAdmin.

Is pgAdmin's ERD tool free?

pgAdmin is open source under the PostgreSQL licence, and the ERD tool is part of it. It works with PostgreSQL.

When do I need a separate database modelling tool?

When the schema leaves relationships undeclared, so a generated diagram shows unconnected tables; when several engines are in the project; or when the diagram has to be saved as a design model, documented and compared with the live database.

Sources

1. PostgreSQL documentation, constraints
2. DbSchema documentation, foreign keys
3. DbSchema documentation, schema documentation
4. DbSchema documentation, schema synchronization
5. DbSchema purchase page