Docs · DBCatz

Queries

The DBCatz Query tab — languages per engine, Run and Format, autocomplete, results, saved queries, history and the Logs tab.

The Query tab is where you write SQL, redis-cli commands, mongosh calls or Elasticsearch requests. On Redis and Valkey it is called Command.

Editor tabs

File → New Query Tab (mod+T), or Query at the foot of the sidebar, opens an editor. Keep as many as you like: each editor is a tab of its own inside the Query view, with + (mod+T) for another and × to close it.

The editor’s buttons

Button Shortcut What it does
Run mod+enter Runs everything, or only the selected text.
Format mod+shift+F Tidies the SQL. SQL engines only (Query → Format SQL).
Save… / Save — Saves the query; Save updates the saved query it came from.
Ask AI mod+shift+K Describe what you want (when AI is on — see AI in DBCatz).

There is no mod+S in the Query tab — use the Save… button.

Format puts each keyword on its own line, upper-cased; quoted text is left alone, and LEFT JOIN / INNER JOIN stay on one line.

Languages per engine

Engine Language Example
MySQL, MariaDB, PostgreSQL, SQLite SQL SELECT * FROM users LIMIT 100;
Redis, Valkey redis-cli commands, one per line, # for comments SCAN 0 MATCH user:* COUNT 100
MongoDB mongosh db.users.find({ status: 'active' }).sort({ createdAt: -1 }).limit(20)
Elasticsearch Console requests GET /products/_search followed by a JSON body

The MongoDB methods DBCatz understands, and the Elasticsearch request format, are on MongoDB and Elasticsearch. Every language is highlighted.

Several statements at once

DBCatz splits the editor into statements and gives each one its own result:

Engine Split by
SQL ;
Redis / Valkey each line
MongoDB lines that start with db. or {
Elasticsearch lines that start with a method (GET, POST, PUT, DELETE …)

An error stops the script at that statement — the ones after it do not run.

Every statement is checked against the connection’s safety mode before it runs — see What asks first.

Autocomplete

Autocomplete is there for every language: SQL, Redis / Valkey, MongoDB’s mongosh and Elasticsearch’s requests.

  • Suggestions appear as you type; Ctrl+Space opens them with nothing typed.
  • ↑ ↓ to move, enter, Tab or → to insert, Esc to close.
Language What it suggests
SQL Statement keywords (sel → SELECT), tables after FROM / JOIN / UPDATE / INTO, columns — alias-aware — and functions.
Redis / Valkey Commands with their argument syntax, key names from a live SCAN, and options.
mongosh Collections after db., methods after db.<collection>., sort / limit … after find(…), and inside the arguments the collection’s fields (from a sample of documents), query and update operators and aggregation stages.
Elasticsearch The method and the path on a request’s first line (index names, then _search, _doc …), and in the JSON body the keys that fit where you are — query types under query, must / filter under bool, gte / lte under a range field, aggregation types under aggs — and the index’s fields from its mapping.

The bar between editor and results

It shows the database the query runs in, and the reminder mod+enter runs everything, or just the selected text · Ctrl+Space suggests.

  • Drag it to resize the editor and the results.
  • Double-click it to fold the results away.
  • Its buttons give the results the full height or fold them.

Results

With several statements, the results get tabs: 1. <statement>, 2. ….

  • A read shows a table. It is capped at the first 5000 rows — add a LIMIT or a filter for more targeted results. Copy CSV and Copy JSON copy what is shown.
  • A write shows N rows affected · ms, or Done.
  • An error shows the server’s message, with Fix with AI when AI is on.

Edit right in the result

A SELECT from a single table that includes its primary key opens in the editable grid: Rows of

— editable like the Data tab; rerun the query to refresh. Everything from Data and JSON works there.

Anything else is read-only: read-only (joins, aggregates or no primary key in the result).

Redis replies

Click a row of a Redis reply to open it in a drawer: Formatted / Raw for JSON or PHP serialize() values, ↑ ↓ between rows, Copy, and the whole reply as JSON — HGETALL and CONFIG GET pairs become an object. Cells holding such a value are marked {}.

The side panel: Tables, Saved and History

The panel beside the editor folds to a thin strip when you need the room. It has three tabs:

  • Tables — click a table to insert its name at the cursor.
  • Saved — your saved queries.
  • History — what you ran.

Saved queries

Save… opens the Save query prompt — Kept for the <db> database of <connection>. Saved queries belong to one database of one connection and are kept on disk, so they are there after a restart. Older saved queries, from before they were per database, show as all databases.

History

History holds the last 50 statements per database — for this window’s life only. It is not saved to disk: quit DBCatz and it is gone. An empty list says Queries you run in <db> show here for this window’s life. Save the ones you want to keep.

The Logs tab

Database → Show Logs (mod+L), or Logs at the foot of the sidebar, shows DBCatz’s own activity on this connection: the queries you ran, your edits in the grid, and structure changes.

Column What it shows
Time When it ran.
What The statement or action.
Rows Rows read or changed.
Took How long it took.

A failed entry shows its error. Filter narrows the list, Errors only hides the rest, and Clear empties it.

The log is kept in memory for the window’s life, up to 500 entries per connection — like History, it is not saved.

It is not the database server’s own log. For a DevCatz service, the server log is in DevCatz — its Database page → Logs.

With AI on, ✦ Ask AI on a row explains an error or a slow statement — see Ask AI in Logs.

Last updated 2026-11-03

← PreviousDatabases, tables and structureNext →Redis and Valkey