Desktop database viewer · PostgreSQL · MySQL · SQLite

Quarry


Edits stay in pencil until you've read the SQL.

Quarry opens your database as a sheet you can scroll, filter and correct. Change a cell and it is pencilled in, not written. Commit, and Quarry rebuilds the statements from your edits, shows you every one, and runs them in a single transaction that checks each row count before anything is kept.

public.ordersTry it
A demonstration orders table. Activate a status to pencil in a new value, then commit.
idstatustotal
10411 240.00
104286.50
1043312.75
104419.99

Statements Quarry would run · rows each must touch

  1. UPDATE "public"."orders" SET "status" = 'paid' WHERE "id" = 1042;1

A demonstration of Quarry's commit: edits are staged, shown as SQL, and posted in one transaction.

A demonstration on this page — no database is involved. In Quarry the statements come from the app's own rebuild of your staged edits, as sheet 02 shows.

01

The sheet

A grid that keeps its types.

The objects tree on the left, the table on the right, virtualised in both directions so a wide table scrolls as easily as a long one. Rows arrive a page at a time. Every value is carried from the Rust side as a typed cell, so nothing is rounded through a JavaScript number on its way to you.

bigint, exact to the last digit
9007199254740993
numeric keeps every decimal
1008.0008
floats shown as they are, not as null
NaN -Infinity
copy a selection in the shape you need
TSV CSV JSON INSERT
Quarry workspace showing the public schema tree and a filled orders grid with typed cells
The objects tree on the left, a filled grid on the right — every column typed, so a uuid, a timestamptz and a jsonb cell look like what they are.
Quarry orders grid filtered to status equals paid, with the SQL preview popover open

Filter without writing SQL

Equals, ranges, contains, starts or ends with, in a list, is null. Then open the preview to read the WHERE clause the grid is using.

Quarry structure tab for public.orders listing columns, types, defaults and comments

Structure, down to the DDL

Columns with type, nullability, default and comment, then indexes, foreign keys and the CREATE statement.

Quarry command palette filtered to orders, order_notes and recent_orders

Open anything with ⌘P

Type a few letters of a table name and you're there, without scrolling the tree.

02

The posting

Nothing is written until the column balances.

Quarry never sends your grid edits straight to the server. They pile up as a changeset you can see, and only a commit turns them into writes.

  1. 1.

    Pencil

    Double-click a cell and type, or insert a row. The change stays marked on the grid until you commit it or discard it.

    ⌘I
  2. 2.

    Rebuild

    Quarry's Rust side writes the SQL from your staged changes. The statements you are shown are the ones that will run, not a copy the interface put together.

  3. 3.

    Read

    The preview lists every INSERT, UPDATE and DELETE in the order it will run, beside the number of rows each must touch.

    ⌘⇧P
  4. 4.

    Post

    One transaction. If any statement touches a different number of rows than it should, the whole batch rolls back.

    ⌘S
Quarry orders grid with the inline cell editor open on the first name
Double-click and type. The value stays staged on the grid until you commit, so a slip is not a write.
Quarry commit preview dialog showing an UPDATE on public.orders for one staged edit
Edit a cell, then Preview — the dialog lists the statements the server rebuilt from your staged edits, in the order they will run.

Safe mode

Safe mode is set per connection, so production can ask more questions than your laptop's SQLite file.

  • Off

    Grid commits: Commits run without the dialog, unless they delete more than ten rows.

    SQL editor: Runs whatever you write.

  • Confirm destructivedefault

    Grid commits: Every commit shows its preview first.

    SQL editor: Asks before any statement that writes rows or changes the schema.

  • Confirm all

    Grid commits: Every commit shows its preview first.

    SQL editor: Asks before every run, SELECT included.


There is no setting that deletes more than ten rows without showing them to you first.

03

The journal

Write SQL beside the rows it returns.

Query tabs use CodeMirror with SQL autocompletion and a formatter. Results land in the same typed grid you browse with. Each query tab holds its own connection, so a transaction you open stays open across runs, and Cancel stops the query on the server, not just in the window.

Saved queries and your query history sit in the sidebar, beside the objects tree.

Quarry query editor with a SELECT on orders and the result grid below
A query tab with CodeMirror, then Run — the result lands in the same grid you browse with, not a separate export.

Index of keys

Run the statement under the cursor
⌘↵
Run all statements
⌘⇧↵
Cancel the running query
⌘.
Format SQL
⌘⇧F
Command palette
⌘K
Open any table
⌘P
New query tab
⌘T
Focus the filter bar
⌘F
Commit changes
⌘S
Discard changes
⌘⇧⌫

Ctrl in place of ⌘ on Windows.

04

The accounts

Your connections stay on your machine.

No account, no sign-in, no Quarry server in the middle. The app talks straight to the database you point it at. Connection profiles are kept in a file on your computer and passwords in your operating system's keychain; the only way to see a saved password again is to click Reveal.

  • PostgreSQL

    Over TCP, with an SSL mode per connection.

  • MySQL · MariaDB

    The same grid, filters and commit preview.

  • SQLite

    Pick a file. Quarry checkpoints it cleanly when you quit.

Quarry connections list with Production Postgres, Staging, Analytics MySQL and Local SQLite
Four saved connections, colour-coded by environment — production, staging and a local file — so you always know which one you are about to open.
Quarry new-connection dialog with PostgreSQL, MySQL and SQLite engine tiles

Paste a connection URL to fill the form, test it, then give it a name and a colour, so production never looks like staging.