A database client should be careful in the right place: change nothing you haven’t seen, and always leave you a way back. Here’s how Kweris does it, point by point, and what it never does.
01
The journey of a change
From a click on a cell to the database, every step can stop it. No step can widen it.
You edit
The cell turns orange: the change waits on your Mac. Nothing reaches the server.
You review
You see the exact SQL statements that will run, the very ones Kweris executes.
One transaction
All together or none: if one fails, the database stays as it was.
One row at a time
Each statement must touch exactly one row. Zero or two: everything is rolled back.
Undoable
The change goes into the Change Log, with the statements that put it back.
1row per edit, never one more
14days of safety copies, on your Mac
30days of Change Log, undoable
0data collected by Kweris
02
Every safeguard, one by one
Four groups: what happens before anything is written, how you go back, what changes on production and what Kweris never does.
01 / 04
Before anything is written
Row changes wait until you review and apply them.
Rows are found by their whole primary key. Without one, the table isn’t edited from the grid: Kweris doesn’t fall back to “all columns”, which can hit several identical rows.
Long, multi-line or binary values are edited in the inspector, with the full value: never starting from the cell’s shortened text.
While changes are waiting, changing page, filters or sort order is blocked; closing the tab or quitting Kweris asks first.
If the connection drops while you apply, Kweris doesn’t retry: it reloads the table and tells you to check.
02 / 04
Going back
Change Log: every row change Kweris made, with the SQL it ran and the SQL that undoes it. Undo works only if nobody changed those rows since.
A safety copy before changing a whole table (UPDATE or DELETE without WHERE, TRUNCATE, DROP): the database file for SQLite and DuckDB, the table as an SQL script for the other engines, up to 200,000 rows.
Before a restore, a copy of the destination database; on PostgreSQL the restore runs in a single transaction.
Copies stay on your Mac for 14 days. The library of your databases keeps a copy a day, the last 14.
03 / 04
Production and read-only
On a production database writes start locked: you unlock them for that window, with Touch ID if you like. Then every write asks first; dropping or emptying a table from the menu asks you to type its name.
When read-only, Kweris refuses every statement that could write, with any engine. On PostgreSQL, MySQL, MariaDB, SQLite and DuckDB the server session is read-only too.
UPDATE and DELETE without WHERE, TRUNCATE and DROP ask first in every environment and, when the engine knows, say how many rows they would touch.
Kweris recognises writes by reading the statement as the server does: comments and quoted text can’t fool it, and writing CTEs, EXPLAIN ANALYZE and functions like pg_terminate_backend count too.
04 / 04
What Kweris never does
Run SQL on its own: kweris:// links, the kweris command, .kweris files, reopened tabs and history open the text, they don’t run it.
Let the Assistant run anything: it proposes SQL, that’s all. To check it, it uses EXPLAIN, only on a single statement EXPLAIN doesn’t execute.
Send several statements as one: on PostgreSQL each of your statements travels alone (extended protocol), on MySQL multiple statements are off, on SQLite only the first one runs.
Repeat a statement after the connection dropped, or run a write again with ⌘R (Refresh).
Create things silently: a SQLite file that was moved or deleted doesn’t become an empty database.
03
Engine by engine
Not every database offers the same guarantees. Where Kweris can’t check the rows before committing, it doesn’t pretend: grid editing and import are off, and you write with SQL, with the same confirmations.
No account, no analytics, no server in between you and your databases.
Kweris collects nothing: it connects only to your servers, to iCloud if you turn sync on, and to kweris.app for updates (version number and language only).
Passwords live in the Mac’s Keychain. SSH is the system’s own (OpenSSH), with your agent and 1Password.
The app is signed with Developer ID and notarised by Apple; updates are signed and verified before they install.
The Assistant works on your Mac: Apple Intelligence, Ollama or a downloaded model. Your tables never leave the computer.
Tested on real servers
Every protection above has its own automated tests, run against live PostgreSQL, MariaDB, MySQL, SQLite, DuckDB, SQL Server, MongoDB, Redis, ClickHouse, CockroachDB, Cassandra and libSQL: changes touching several rows rolled back, multiple statements refused, undos that never overwrite someone else’s work.
Found a problem?
Write to [email protected]: a report about data or security comes before everything else.
No software is bug-free
Kweris isn’t either. That’s why it doesn’t rely on having none: every protection on this page is there so that a mistake, ours, yours or the server’s, stops before your data.
