pgAdmin 8.1 generates schema diagrams with a defined boundary
Schema-level ERD generation gives pgAdmin a narrower view of an existing database. Cross-schema foreign keys are omitted, so the generated diagram has a specific scope.
A schema diagram can hide a real dependency when the referenced table belongs to another schema. pgAdmin 4 v8.1 adds schema-level entity-relationship diagram generation, but its documentation explicitly removes links to tables outside the selected schema. That makes the new command useful for examining one part of a database while imposing a clear limit on what the drawing establishes.
The December 15 announcement introduces schema ERD generation and creation of functions with custom return types. The versioned release notes date the release itself December 14. This post uses the later public announcement date, so both the release documentation and announcement belong to the information available at publication.
I prefer PostgreSQL schemas that make relationships explicit. A diagram helps explain those relationships when its scope is clear. An absent line in a schema-only view should not become an architectural claim that the selected tables have no dependencies elsewhere.
Three generation scopes answer different questions
The ERD documentation pinned to 8.1 distinguishes database, schema and table generation. Database generation retrieves tables across all schemas and draws their foreign-key relationships. Schema generation retrieves tables within one schema and drops a link when its target belongs to another schema.
Table generation follows tables linked directly or indirectly to the selected table. Its traversal depth can be changed in preferences. That is a different selection rule from choosing every table within one namespace. A table-centered dependency exploration and a schema inventory need not produce the same set of nodes.
The new schema command therefore provides a useful middle scope. A whole-database drawing may include more tables than the reader needs for a particular discussion. A table-centered traversal may instead follow relationships away from the namespace of interest. Selecting a schema gives a predictable set of included tables, while deliberately excluding outward relationships that would require additional nodes.
The excluded links are a presentation decision. The documentation does not say that generating the diagram removes foreign keys from the live database. It describes which relationships the generated ERD contains. Keeping those levels separate avoids confusing reverse engineering a selected subset with modifying the source schema.
Reverse engineering must preserve column meaning
Version 8.1 also corrects reverse engineering of serial columns when generating database or table diagrams. That fix belongs next to the new generation scope because a diagram is useful only if its representation of columns matches the source objects. The release notes identify the correction without claiming that every database definition can round-trip through the tool without qualification.
The ERD tool can generate SQL from a design and open that SQL in a query tool. It also offers an option to include table-drop statements before creation statements. Those are explicit output actions, separate from loading an existing database into a diagram. A reader inspecting relationships is not automatically asking the tool to execute replacement DDL.
Relationship editing has its own database meaning. The documented one-to-many dialog adds a foreign-key relationship between two tables. The many-to-many dialog creates an additional relationship table and links it to the two selected tables. A line introduced during design can therefore imply more than a visual annotation, which is another reason to inspect generated SQL before treating the diagram as a migration artifact.
Saving and reopening diagrams supports a continuing design discussion. The documentation also permits notes and moving table nodes, which helps present selected relationships without changing their source definitions. Those conveniences belong to the diagram artifact. The database remains the source when the objective is to understand what constraints currently exist.
My preference is to treat a generated drawing as a scoped explanation of the catalog. Its value comes from exposing actual relationships with enough context to show what was included. For this release, the documented omission of cross-schema links is part of that context.
Object visibility and deployment receive separate fixes
The release notes also correct visibility of indexes created by constraints in Object Explorer when Show system objects is enabled. That concerns another representation of database structure. An object's absence from a particular interface view is not sufficient evidence that PostgreSQL did not create it.
Other corrections address the management application itself. Version 8.1 fixes process-log reading when DATA_DIR moves to a network drive and ensures the correct time zone for Docker deployments. Those issues have different operational scope from SQL constraint enforcement. They concern pgAdmin's own deployment and display behavior.
The version supports PostgreSQL and EDB Advanced Server 12 through 16, and bundles PostgreSQL utilities at version 16.0. That identifies the client release's stated compatibility and utility versions without implying that the management interface upgrades a database server. For schema exploration, the concrete addition remains generation of an ERD for one schema, with its documented treatment of foreign keys leading outside that schema.