pgAdmin 6.18 moves desktop menus into the native runtime

A desktop wrapper around a web application has to decide which parts of the interface belong to the host platform. Rendering everything inside the application window is convenient for shared implementation, but a menu is also a familiar operating-system control. pgAdmin 6.18 moves its top-level desktop menu through that boundary.

The December 20 release announcement says the desktop application now converts its top-level menu to a native menu using NWjs. The result follows the platform on which it runs. This is specifically a desktop-mode change, with an existing runtime providing the mechanism.

I care about administration tools being predictable during ordinary work. PostgreSQL remains my default relational database, and the client used to inspect it is part of that work. A menu that follows the host platform is a modest improvement with a concrete implementation behind it.

The desktop application already includes a server

The desktop deployment documentation at the 6.18 tag explains that the runtime launches the pgAdmin server and opens a window rendering its interface. NWjs integrates the browser and Python server into a standalone application. Desktop deployment therefore does not mean replacing the web implementation with a separate database administration program.

The menu change uses that arrangement. A native runtime can represent an application command through a platform menu while the broader interface continues to run through the existing application. The announcement makes a claim about the menu representation, not a rewrite of every panel or dialog.

That scope matters for understanding which installations receive the change. A server-mode deployment accessed through an ordinary browser does not acquire an NWjs desktop runtime merely by updating the server package. The feature is tied to the desktop application hosting the interface.

The documentation says server mode is the default configuration from version 2 onward, but the desktop runtime overrides that at startup. In most environments, desktop users do not need Python configuration solely to select that mode. The packaged runtime establishes the intended arrangement.

Runtime controls remain distinct from database controls

The same documentation places runtime commands under the File menu. These include opening runtime configuration and viewing the pgAdmin server log. They concern the local application hosting pgAdmin, rather than changing a PostgreSQL server setting through a database connection.

Runtime configuration can choose a fixed network port and a startup timeout. The fixed-port choice replaces the default random-port arrangement, while the timeout controls how long the runtime waits for its application server. These controls make sense because the desktop application starts a server process even though the user interacts with a standalone window.

The documented log dialog also reads the pgAdmin server log and can reload its contents. That is distinct from interpreting a PostgreSQL server log. The runtime can fail to launch its application before any database connection occurs, so a database-level diagnostic would answer a different question.

I find this distinction useful when evaluating desktop administration software. The local runtime and the remote database have different settings and failures. Exposing runtime commands through the desktop menu makes their ownership clearer without changing what PostgreSQL itself does.

Generated SQL still needs precise repairs

The 6.18 release notes include a missing tablespace in SQL for partitioned tables and an error in the PostgreSQL 15 collation creation script. These repairs affect statements the administration client generates. They should not be read as changes to the server's underlying SQL syntax.

That difference is consequential for a graphical tool. A user can choose an object property correctly while the generated statement omits it or represents it incorrectly. Inspecting generated SQL is useful, but the client still needs to encode its model accurately. A repair to the generator changes the statements available for subsequent operations.

The release also fixes autocomplete around double quotes. Identifier entry is a separate concern from the native top-level menu, but both affect how users select and express an operation. The notes identify the particular completion problem without claiming that every possible quoting issue has changed.

Another fix prevents the properties tab from refreshing when changing tabs while the selected node remains the same. It reduces an unnecessary interface action associated with navigation. This is a client-state correction, with a different scope from either SQL generation or server execution.

Password controls are part of interface correctness

Two listed repairs concern saved-password handling. Updating server-node information could remove the clear-saved-password menu, and the master password could be set incorrectly with an external configuration database. The release notes identify both conditions explicitly. They do not describe a new PostgreSQL authentication method.

The first repair restores access to a command in a changing interface. The second concerns how pgAdmin handles its master password with a particular configuration-storage arrangement. Keeping these descriptions narrow avoids turning a maintenance entry into an unsupported security claim about exposure or encryption.

Version 6.18 combines the native desktop menu with these specific administration repairs. Its announcement provides desktop packages alongside other distribution forms, but the menu feature depends on running in desktop mode. The shared application continues to provide database administration, while NWjs supplies the platform menu and the local runtime controls associated with hosting it.