pgAdmin 4.30 makes foreign keys part of visual schema design
The beta ERD tool generates SQL from a diagram and reconstructs diagrams from existing databases. Its relationship controls expose the relational structures behind the drawing.
A line between two tables leaves an important question unanswered until it identifies the columns that implement the relationship. pgAdmin 4.30's new entity-relationship diagram tool makes those columns part of the editing workflow. Its one-to-many dialog asks for the referencing and referenced columns. Its many-to-many dialog creates an intervening table. Those decisions determine the database structure that the diagram will generate.
The January 28 announcement introduces the tool as a beta. It supports designing a schema and generating its creation SQL, as well as generating a diagram from an existing database. That makes the release relevant both to an empty database and to a schema whose relationships already exist. The interesting question is how closely the drawing corresponds to the structures that PostgreSQL will enforce.
I default to PostgreSQL for relational work, and I want a design tool to make the schema easier to inspect. A picture becomes useful when someone can follow a relationship down to the columns involved. The initial ERD implementation gives those columns explicit positions in its controls.
Relationships have a direction
The ERD documentation shipped with 4.30 describes the selected table in a one-to-many relationship as the referencing table. That table receives the many endpoint. The dialog separately identifies the local table and column, then the referenced table and column. Selection therefore affects the relationship's direction before the user completes the dialog.
For a schema involving customers and orders, an order's customer column belongs on the referencing side. The diagram's single-line endpoint identifies the referenced column, while its three-line endpoint identifies the column containing the reference. These visual conventions help a reader distinguish which table holds the foreign key without opening every table dialog.
The distinction also matters during editing. The documentation says that removing either column involved in a relationship drops the link. A relationship is attached to specific columns, so changing the table's structure can change the diagram's connections. This behavior makes column-level review necessary even when the overall arrangement of tables looks familiar.
The table nodes expose the underlying details. They show the schema name, table name and columns with their data types. A key icon identifies a primary-key column. Double-clicking a node opens its table dialog, and a details control changes how much column information appears. A compact diagram can support navigation, while the expanded view supports checking the columns behind a relationship.
Many-to-many design creates another table
The many-to-many operation deserves particular attention because it creates database structure. According to the versioned documentation, the dialog derives columns from the two participating tables and creates a relationship table linked to both. The chosen left and right columns are primary keys in their respective tables.
Consider a design in which a project can have several members and a person can belong to several projects. The relationship requires somewhere to represent an individual association between a person and a project. The tool's generated intermediate table gives that association a concrete place in the design. Both original tables have one endpoints on their links to the new table.
That generated table also becomes an object to inspect in its own right. Its columns and connections belong in the schema review alongside the original tables. The many-to-many button saves manual construction, but the result still has a table definition whose details affect the database. The release notes describe the initial scope as basic table fields, primary keys, foreign keys and DDL generation.
I find that scope sensible for a beta. Foreign keys and their columns provide enough structure to make a diagram informative. A design discussion can then refer to the actual relationship table and its keys instead of treating an association as an unexplained line.
Generated SQL remains visible
The tool's Generate SQL command opens the Query Tool with the diagram's DDL ready for execution. This creates an inspection point between the visual design and the database operation. The user can read the statements in the same environment used to execute them.
The diagram itself has a separate save workflow. Open, Save and Save As preserve the diagram for later work. Saving a design and generating its SQL are distinct operations in the documented interface. This distinction matters when discussing whether a proposed edit exists only in the saved design or has been applied to a database.
Notes attach further context to table nodes. A node with a note displays a note button, which reopens the text for inspection or editing. Notes can record why a relationship exists without requiring that explanation to fit inside a table name. Automatic alignment and zoom-to-fit address the practical problem of navigating several connected tables on a canvas.
The 4.30 release notes identify ERD implementation as issue 1802 and its documentation as issue 6152. Those separate entries help define what is available in this first beta. The release supplies a documented path between tables, relationship dialogs and generated DDL. Reverse engineering an existing database supplies the other starting point, allowing its current schema to become the material for the diagram.