Safety and production
A database client has two ways to hurt you: running something you did not mean to run, and leaking something it should have kept. PlumeSQL answers the first with guards that can only tighten along the settings chain, and the second with a model in which a password never leaves the machine and the server only ever listens on loopback.
Read only
A connection or a group can be read only. It is enforced by PostgreSQL itself (default_transaction_read_only), not by the client guessing at your SQL, and it is escalate-only: a file's -- @readonly line or a colleague's script can tighten your safety but never loosen it.
The production guard
The guard has two axes, each with three answers:
- structure changes (
connection.guardSchema): CREATE, ALTER, DROP and friends; - data changes (
connection.guardData): INSERT, UPDATE, DELETE, TRUNCATE.
Each is Allow, Ask first (one confirmation per run) or Block (the run is refused). Every statement is classified before it is sent, and the editor's statement marks show the verdict in the gutter before you run. The policy resolves global, then workspace, then the connection's group, then the connection, the most specific explicit value winning, and a stricter answer down the chain always stands. The guard is a seatbelt, not a lock: only Read only is enforced by the server.
The commit gate
With connection.confirmCommit on (the default), a COMMIT asks first, with what the transaction counted since BEGIN: structure changes, data changes and their rows. A transaction that counted nothing commits without a word.
The change chronicle
connection.logChanges writes an INFO entry to the Log, SQL included, for every run that changed structure or data, counted from PostgreSQL's own command tags. The default, tx, records runs inside an open transaction; always records every such run. The Log is an append-only file per workspace, so the chronicle outlives the session.
The Production group
Four groups ship seeded: Production, Staging, Development and Local. Production is guarded, and it silences the parsers.
Production silences the parser
On a connection in the Production group nothing goes to the server without your knowledge and gesture. The dynamic parser is off (editor.liveParse), a tab that has not connected gets no throwaway dial to check it (parser.checkUnconnected), and the routine body analysis, whose probes are the parser's own Parse, is off with it. A file's own -- @parse line is such a gesture and can ask for one. The Problems tab stays empty on production by design.
Grid edits are fully parameterized and refused when they would match more than one row. Values an extension inlines (@inline) are quoted by PostgreSQL itself.
Passwords never leave the machine
A connection's password is never sent to the page, is stripped from every API response and is never round-tripped: editing a connection with a blank password field keeps the secret. A command extension spends it only through the child process's environment, never through an argument list (every process on the machine can read those), never into SQL, a file name or a Log line. The {password} placeholder is allowed on a command's @env line and refused everywhere else, by both parsers and again by the server.
If you prefer not to store a password at all, leave the field empty and rely on ~/.pgpass.
The vault and the keyring
Saved connections live in a vault sealed with XChaCha20-Poly1305. Its 256 bit key is kept by the OS: the macOS Keychain, Windows DPAPI or the Linux Secret Service. A machine with no usable keyring gets a key file readable only by you, always in a different directory than the vault, so copying either one alone reveals nothing. The System page says in words which of these holds your key.
A loopback-only server
The local server binds 127.0.0.1 only. Every request's Host header must resolve to a loopback or private address, which blocks DNS rebinding from a malicious web page, and a non-loopback Origin is rejected outright, closing CSRF. Result views run in a sandboxed iframe with no network of its own; a CDN host has to be allowlisted explicitly (extensions.remoteScriptHosts).
Discovery reads the project's config files statically and never executes project code.
No telemetry
No account, no telemetry: PlumeSQL sends nothing about you or your databases anywhere. It goes online only for updates and release notes, the extension catalog with its download counts and comments, the video list, the PostgreSQL documentation pages you open, Open VSX when you browse its themes, and YouTube when you press play. An extension's chart libraries and map tiles come only from hosts you allow, and the System page lists every host PlumeSQL reaches. Every SQL statement PlumeSQL runs on its own initiative is inventoried and audited.
SSH host keys
WARNING
SSH tunnels accept the server's host key without verification, the usual trade-off in GUI database clients: traffic is encrypted, but first-contact spoofing is not detected. Use a bastion you trust.