pgAdmin 6.4 makes server definitions portable through the GUI

A database administration tool accumulates connection settings that can be tedious to reconstruct on another installation. Server names and groups give those settings an organization that matters to the person navigating them. pgAdmin already supported transferring this configuration through its command-line setup script. The pgAdmin 4 version 6.4 announcement, published on January 13, adds a graphical wizard for the same task.

The change concerns the configuration of the administration client. Exporting a server definition does not export the database behind that definition. The JSON describes how pgAdmin should identify and connect to a server. This distinction explains both the usefulness of the feature and the limits of what a transferred file can establish on another machine.

I default to PostgreSQL for relational work, and its administration tools matter to that choice. Moving a known set of connection definitions is a useful reduction in repeated configuration. The important detail is that the format has an explicit boundary around passwords.

The transferred object is a connection definition

The import and export documentation shipped with version 6.4 describes a JSON object containing server definitions. Each definition needs a name, group, port, username, SSL mode, and maintenance database. It must also provide a host, host address, or service. These fields identify a connection and the group under which pgAdmin displays it.

Here is a minimal example using the documented format. The host and username are illustrative values for a local installation.

{
  "Servers": {
    "1": {
      "Name": "Local development",
      "Group": "Development",
      "Port": 5432,
      "Username": "postgres",
      "Host": "localhost",
      "SSLMode": "prefer",
      "MaintenanceDB": "postgres"
    }
  }
}

The documentation explicitly excludes password fields from import and export. A recipient therefore receives the connection description without receiving the saved password through this mechanism. That makes the file useful for preconfiguration, but it does not make every connection immediately usable. Authentication still needs the credentials appropriate to the destination environment.

The fuller documented example also includes paths to a password file and certificate files. A transferred path is a reference to a file, not the contents of that file. Copying a definition containing such a path cannot by itself establish that the destination has the referenced material. This follows directly from what the JSON contains and is a practical reason to read the exported settings before treating them as a complete client configuration.

The wizard exposes an existing operation

Version 6.4 puts Import/Export Servers under the Tools menu. The first step chooses import or export and a JSON filename. Import also offers a choice to remove existing servers before loading the selected definitions. Subsequent steps select server groups or servers and show a summary. The operation is therefore selective, with a chance to inspect the intended transfer before finishing.

That removal choice changes the meaning of an import. Adding definitions preserves an existing collection, but can produce duplicates. Replacing definitions changes the destination collection to the imported selection. The versioned documentation describes the corresponding command-line behavior explicitly. Import adds servers by default, and the replacement option overrides that behavior.

The command-line route remains documented alongside the wizard. Using placeholder installation paths, its basic forms are these.

/path/to/python /path/to/setup.py --dump-servers servers.json
/path/to/python /path/to/setup.py --load-servers servers.json

The Python interpreter must be the one normally used to run pgAdmin so that the necessary packages are available. The documentation also provides options to choose the owning user and the pgAdmin configuration database. Those choices matter when an installation has more than one configuration. The file being transferred describes server connections, while the configuration database determines which pgAdmin installation receives them.

I like the continuity between the two interfaces. The GUI makes a documented configuration operation accessible without locating the correct Python environment. The script still describes how to perform the same transfer in a repeatable command, including explicit ownership and destination settings.

Correct administration depends on accurate displays

The release also repairs several places where the interface could misrepresent an operation or a query plan. The version 6.4 release notes list a fix for negative exclusive time in EXPLAIN ANALYZE and another for SubPlans overlapping other nodes in graphical EXPLAIN. Overlapping SubPlans could make nodes inaccessible. These are relevant to interpreting a plan through the graphical tool, even though the announcement does not claim a change to PostgreSQL execution itself.

EXPLAIN is one reason I value PostgreSQL. A graphical presentation needs to preserve access to the plan and avoid misleading timing displays. A repair to that presentation matters because an engineer can otherwise spend time investigating an apparent property of a query that comes from the client display.

Other fixes address generated SQL and object dialogs. The notes identify a missing procedure owner in reverse-engineered SQL, an issue generating SQL for PostgreSQL 14 functions, and unwanted line endings in schema-diff scripts for functions and procedures. A separate fix concerns tablespace creation succeeding while the dialog reports an error. Each case affects the relationship between what the interface presents and what an administrator can infer from it.

The server-transfer wizard belongs to that same administration context. A definition file makes connection configuration inspectable before import, and its documented fields make the transfer understandable outside the GUI. Passwords remain excluded, while destination-specific references still require their corresponding files. That is enough to move a useful connection catalog without confusing it with a database backup or a complete authentication setup.