v0.3.0 was about what you can do inside the query editor. v0.3.2 is about getting data in and out of a database: a full Export sheet backed by pg_dump, an Import sheet backed by psql, and the plumbing that finds those binaries on your Mac — including a keg-only brew install libpq that a Finder-launched app would otherwise never see.

Export: the pg_dump options that actually matter

The Export sheet is a real front end for pg_dump, not a one-button “save a .sql file”. You pick an output format first, and the sheet adapts:

Plain SQL — a .sql script you can re-import right here with the new Import sheet, or pipe through psql anywhere.
Custom (compressed) — a .dump archive for selective, parallel restores with pg_restore; accepts a -Z compression level.
Directory — one file per table in a folder, also restorable in parallel and the only format that compresses per-object.
Tar archive — a single .tar restorable with pg_restore.

Then you choose scope — schema + data, schema only, or data only — and narrow the object set: include or exclude specific schemas, include or exclude specific tables. The rest is the long tail of pg_dump flags people actually reach for, each a labelled toggle: --no-owner and --no-privileges for portable dumps; --clean / --if-exists / --create for a DROP-and-recreate preamble (with --if-exists gated behind --clean, the same way the tool itself treats it); --inserts or --column-inserts for portable (if slower) data; --no-comments, --no-large-objects, --quote-all-identifiers, --no-tablespaces, a per-archive compression level, and a target encoding. Progress streams line by line from pg_dump --verbose into the sheet as the dump runs, so a large export shows you what object it is on rather than spinning a beach ball.

Credentials never touch the command line

The interesting engineering is in how the child process is launched. The password and SSL mode are passed to pg_dump / psql through the environment (PGPASSWORD, PGSSLMODE), never as arguments — so they can’t leak into a process listing. --no-password guarantees the tool never blocks waiting on a prompt that has no terminal to answer it. And every value-bearing flag uses the --name=value long form: a schema or table name that happens to begin with - can’t be re-parsed by pg_dump’s getopt_long as another option. The whole argument vector is built by a pure, value-typed ExportOptions / ImportOptions model that is unit-tested without a live database, the same approach the cascade- delete builder uses.

For SSH-tunneled connections the export dials the loopback forwarding port owned by the live connection, not the remote host from the saved profile — the dump goes through the same tunnel your browsing session already uses.

Import: run a .sql file through psql, safely

The Import sheet runs a .sql file through psql against the active connection. Two safety toggles, both on by default, decide what happens when a statement fails: single transaction (--single-transaction) wraps the whole file so any error rolls everything back, and stop on first error (ON_ERROR_STOP=1) aborts instead of plowing ahead. --no-psqlrc means your personal ~/.psqlrc can’t change the outcome, so an import behaves the same on any machine.

Finding pg_dump and psql — even keg-only libpq

SequelPG doesn’t bundle the PostgreSQL client tools, because they should match your server’s major version. It finds your existing install instead — and that detection got noticeably more robust in this release. A macOS app launched from Finder or the Dock inherits launchd’s minimal $PATH, not the $PATH from your shell’s startup files. On top of that, keg-only Homebrew formulae — including libpq, the exact package the “tools not found” screen tells you to install — are never symlinked into /opt/homebrew/bin. The result was a confusing state where pg_dump ran fine in your terminal but the app swore it didn’t exist.

v0.3.2 searches the places those binaries actually live: a directory you set in Settings → General first, then the Homebrew prefixes, then the keg-only locations — /opt/homebrew/opt/libpq/bin and /usr/local/opt/libpq/bin unconditionally, plus any installed postgresql@N keg discovered dynamically, newest major first — then Postgres.app, the EDB installer, and finally whatever is on the inherited $PATH. So a plain brew install libpq now just works, with nothing to configure. If your tools live somewhere unusual, the Settings pane still lets you point at the directory by hand and shows you the detected version of pg_dump and psql as confirmation.

Concretely, v0.3.2 means

New Models/DatabaseTransfer.swift with the value-typed ExportFormat, ExportContent, ExportOptions, and ImportOptions models that render themselves into pg_dump / psql argument vectors
New Services/DatabaseTransferService.swift launching the child process with credentials in the environment, streamed stderr progress, and cancellation
New ExportSheet / ImportSheet views and their ExportViewModel / ImportViewModel, plus a shared ToolMissingView empty state
Hardened Services/PGToolchain.swift discovery that adds the keg-only libpq and postgresql@N bin directories so an installed-but-unlinked pg_dump / psql is found without touching $PATH
A Settings → General tools-directory picker with live detection rows showing the located binary and its version

Grab v0.3.2 from the latest release or build from source with Xcode. If you have ever wanted to take a quick backup of a table before a risky migration, or move a schema between two connections, the Export and Import sheets are now one ⌘-click away.