Documentation

Database studio

A full client for five engines — the same saved connections your agents use, so credentials live in one place and access is granted in one place.

Engines & connections

Five engines, first-class, with the same UI over each: PostgreSQL, MySQL, SQLite, MongoDB and Redis. Connections are saved per project or globally; passwords go to your chosen secret backend, never into a config file.

Connections support TLS. Postgres takes the full sslmode ladder — disable, allow, prefer, require, verify-ca, verify-full — with allow resolving to prefer (plaintext only if the server refuses TLS), and an unrecognised value rejected rather than quietly downgraded.

Every encrypted mode verifies the server certificate, which is deliberately stricter than libpq — there, require encrypts against any certificate at all. Here prefer, require, verify-ca and verify-full all validate the chain, so a self-signed server is refused until you point sslrootcert at its root — which is added to the system trust store, not substituted for it. verify-ca is the one mode that skips hostname validation, exactly as in libpq; the others check the hostname too. "Trust any certificate" is not an option Muster exposes.

Client-certificate (mutual TLS) authentication is supported: give the connection an sslcert and a matching sslkey (PKCS#8) and Muster presents that identity on the handshake. One without the other is refused up front rather than silently connecting unauthenticated. Engine-specific knobs (a Mongo authSource, for instance) are carried as connection extras.

A connection can point through an SSH tunnel to a host you have saved, which is how you reach a database that is not exposed to the internet.

Browsing, querying & editing

Tree of namespaces → objects, including views and materialised views (which information_schema-only clients miss).
Describe an object: columns with types, nullability and primary keys, plus indexes — with their columns in index order, which is the order that decides whether an index can serve a query — and foreign keys. On MongoDB the field list is inferred from a sample of documents while the indexes are exact; Redis has no schema of that kind, so describing a key reports its type.
Preview a bounded page of rows without writing SQL.
Run queries with results in a grid; edit rows in place where the object has a usable key, with row identity handled for you rather than surfaced as a column.
Read a query plan — always a plain EXPLAIN, never EXPLAIN ANALYZE, so producing a plan can never execute the statement.
Save queries per connection.

Backup & restore

Native and in-app: no pg_dump, mysqldump, mongodump or redis-cli needed anywhere on your PATH. Everything runs over the live connection.

Engine	Backup format	Restore behaviour
PostgreSQL	Logical `.sql`, plain or gzipped (`.sql.gz`), including views and materialised views	Replays into the connected database; can restore into a different one
MySQL	Logical `.sql`, plain or gzipped (`.sql.gz`), with `CREATE DATABASE`/`USE`	Destructive same-database replace
SQLite	`VACUUM INTO` — a consistent, fully-checkpointed snapshot file, taken through the live connection — or a logical `.sql` script	File replace, after the source's `SQLite format 3` header is verified; a script restores as one transaction
MongoDB	JSON-lines archive per collection, or a pretty per-collection `.json` export	Format auto-detected by content; restores into a target database you name
Redis	`DUMP`/`PTTL` archive per key	`RESTORE … REPLACE` into a target logical database

What the logical .sql dump does not carry. It is data plus core structure, not a physical replica. Postgres, MySQL and SQLite-as-.sql all emit tables (columns and primary key), views and every row; they do not reproduce secondary indexes, non-PK constraints (foreign keys, CHECK, UNIQUE), sequences, defaults and identity, triggers, stored routines, or partitioning — a Postgres partitioned parent restores as a plain heap table. Each dump writes that same list into its own header, so it travels with the file. Tables are read one at a time, so a single enormous table is held in memory while it is written.

Restores are re-runnable: running the same restore twice lands the same state instead of failing halfway. That includes the awkward cases — a materialised view a naive DROP VIEW would reject, and a target that already holds an unrelated object of the same name.

A SQL restore is also checked before it starts: the whole script is scanned for an unclosed quote or block comment before its first statement runs, so a truncated or corrupt file is refused while the database is still intact — which matters because the destructive DROPs come first in the script. The replay is then wrapped in one transaction, which on Postgres and SQLite (transactional DDL) makes a failure genuinely all-or-nothing; MySQL commits implicitly at every DDL statement, so there the pre-scan is the guard that counts.

Restore is destructive by design: objects of the same name are dropped and recreated. Restoring into a scratch database first is the safe habit, and the cross-database restore path exists precisely for that.

New here? Start the 7-day trial — every feature, card up front, $0 today, key on screen. Or buy outright: $39 once per device, no subscription.