Your psql, mysql and sqlcmd commands, inside a GUI

The reflex a GUI usually breaks

Anyone who has lived in a terminal client types `\dt` before they think about it. Paste that into a graphical SQL editor and the server answers with a syntax error, because a backslash command was never SQL in the first place: psql resolves it locally and sends a catalog query of its own. The same goes for `.tables` in sqlite3, `:help` in sqlcmd and `show collections` in mongosh.

So you end up with two tools open. The GUI for the grid, the result export and the schema tree; the terminal for the fifteen short commands that are faster to type than to click. Rowset Studio's answer is not to teach you a new command set. It is a console that already speaks the client you have muscle memory for.

-- In a plain SQL editor, this is not a statement:
\dt

-- ERROR:  syntax error at or near "\"

One console per engine, each with its own dialect

Open the console on a connection and the prompt names the engine, the hint line names the terminator, and the help command lists exactly what that engine's console understands. Thirteen engines map onto nine command sets, each named after the client it came from — so a CockroachDB connection gets psql's commands under a `cockroach` prompt and MariaDB gets the `mysql` set, because that is what those clients actually do.

The command names are not aliases over one invented vocabulary. `\dt` lists tables on PostgreSQL, `.tables` does it on SQLite and DuckDB, `show collections` on MongoDB, `describe tables` on Cassandra, `show indices` on Elasticsearch. The terminator follows the client too: a semicolon almost everywhere, `GO` on its own line for SQL Server, and no terminator at all for MongoDB, Redis and Elasticsearch, where one line is one command.

Type SQL ending in ';', or a \ command. \? lists them.postgres=# \dt ord*
       List of relations
 Schema |    Name     | Type
--------+-------------+-------
 public | orders      | table
 public | order_items | table
postgres=# \d orders
  Column   |     Type     | Nullable
-----------+--------------+----------
 id        | integer      | not null
 status    | text         | not null
 total     | numeric(10,2)| 
postgres=# ▋

What each client dialect gives you

PostgreSQL gets the fullest set, because psql's is: `\l` for databases, `\c` to switch, `\dn` for schemas, `\dt` `\dv` `\di` `\ds` `\df` for tables, views, indexes, sequences and routines, and `\d` to describe one object or list them all. `\?` prints the list.

MySQL and MariaDB keep `use`, `\u`, `status` and `\s`, and `\h` or `help` for the list — while `SHOW` and `DESCRIBE` are left alone, because on MySQL those are real server statements and the server answers them better than any client could. SQL Server takes T-SQL with `GO` on its own line, plus `use`, `:connect`, `:help` and `:exit`. SQLite and DuckDB answer to `.help`, `.databases`, `.tables`, `.schema`, `.indexes` and `.timer`. ClickHouse keeps `\l`, `\dt`, `\d` and `use`.

Four display commands are shared by every SQL console, because every client has them under one name or another: `\x` switches between aligned columns and one field per line, `\timing` shows how long each statement took, `\clear` wipes the screen and `\q` closes the console.

postgres=# \dt ord*
postgres=# \d orders
postgres=# \timing

mysql> SHOW TABLES LIKE 'ord%';
mysql> status

mssql> SELECT TOP 10 * FROM orders;
mssql> GO

sqlite> .schema orders

A pattern behaves the way you expect it to

Listing commands take an optional pattern, and the pattern rules are deliberately forgiving. `*` and `%` both mean any run of characters, `?` and `_` both mean one, and matching ignores case — so a habit picked up from `LIKE` works next to one picked up from a shell.

Plain text with no wildcard at all is treated as a substring, not an exact name. psql's `\dt ord` matches only a table called `ord`; here it also matches `orders` and `work_orders`, because that is what every other client's users assume, and an empty list is a worse answer than a slightly wider one.

\dt ord*      -- orders, order_items
\dt %order%   -- orders, work_orders, order_items
\dt ord       -- same: no wildcard means "contains"

Nothing in the console gets to skip the guardrails

This is the part a terminal cannot give you. The console does not hold a connection of its own and never talks to a database directly: a statement typed at the prompt is sent to the very endpoint the editor uses. It gets the same policy check, the same row backup and the same audit entry it would have got in a query tab.

So a `DELETE` without a WHERE clause is refused at the prompt exactly as it is refused in the editor, by the default policy rather than by a separate rule the console carries. An eligible `UPDATE` run from the console appears under Activity → Row backups with its prior values saved, and Restore works on it. A policy notice comes back inline, under the result it belongs to.

Meta commands are the one thing resolved locally, and they are reads: the console answers `\dt` or `.schema` from the connection's schema information rather than inventing a catalog query per engine. One implementation sits behind every engine's name for the same action, which is why `\dt`, `.tables`, `show collections` and `describe tables` behave identically once you look past the spelling.

The engines that were never SQL

A console only helps if it keeps the shape of the thing it is a console for. MongoDB takes `db.collection.find({…})`, `aggregate`, `updateOne` and `deleteOne`, with `show dbs`, `show collections` and `use`, and prints documents as documents rather than squeezing a forty-field object into one grid cell. Redis and Valkey take `KEYS`, `SCAN`, `GET`, `SET`, `DEL` and `TTL`, with `select` for the database index.

Cassandra takes CQL with `describe keyspaces`, `describe tables` and `use`. Elasticsearch takes a search body as JSON, the way the Kibana console does, plus `show indices` and `use`. In each case the prompt names the client those commands came from, so what to type is a question you have already answered elsewhere.

mongodb> show collections
mongodb> db.orders.find({ status: "pending" }).limit(10)

redis> SCAN 0 MATCH session:* COUNT 100
redis> TTL session:91f3

cqlsh> describe tables
cqlsh> SELECT * FROM orders LIMIT 10;

And the actual command line is one command

Rowset Studio's own CLI is deliberately small. `rowset desktop` starts the local workspace and opens it; `desktop` is the default command, so a bare `rowset` does the same. `rowset desktop-stop` stops the running instance — which is what the install scripts call before replacing the binary. `rowset --version` prints the version and `rowset --help` prints the list.

`--config <path>` points at an environment file and works with any command. There is no `rowset query`, no `rowset migrate` and no daemon to register: the executable is the workspace, it runs on your machine, and the console inside it is where the per-engine commands live.

$ rowset --help
rowset 0.1.9

USAGE:
  rowset desktop        start and open Rowset Studio
  rowset desktop-stop   stop the running Rowset Studio
  rowset --version

$ rowset desktop --config /etc/rowset.env