Edit a SQLite Database on a Remote Server as if It Were Local — Over SSH, with Auto-Sync

If you've ever shipped a small app to a Linux box, you know the SQLite ritual.

The database is a single file sitting somewhere like /var/lib/myapp/app.db. You need to fix one bad row. So you SSH in, try to remember whether sqlite3 is even installed, fumble through .headers on and .mode column, squint at unaligned output in a terminal, hand-write an UPDATE, pray you got the WHERE clause right, and hope you didn't just corrupt production.

Or you scp the file down, open it in a GUI, make your edits, and scp it back — and now you're manually playing the role of a sync engine, hoping nobody wrote to the server in between.

There's a better way. DBGridy lets you open a remote SQLite file over SSH and edit it in a proper data grid — and every change you make is synced back to the server automatically, the moment you make it.

No terminal gymnastics. No manual upload. No "wait, which copy is the real one?"

The 30-second setup

Remote SQLite isn't a separate mode you have to learn. It's just a connection string. Instead of pointing Data Source at a local path, you point it at an ssh:// URL:

Data Source=ssh://deploy@db.example.com:22/var/lib/myapp/app.db?authType=password&password=•••••

Prefer key-based auth? DBGridy speaks that too:

Data Source=ssh://deploy@db.example.com:22/var/lib/myapp/app.db?authType=key&keyPath=C:\Users\me\.ssh\id_ed25519&passphrase=•••••

Connect, and the remote database shows up in the tree view exactly like a local one — tables, views, triggers, schema, the works. Double-click a table and you're looking at your rows in an editable grid.

What actually happens under the hood

This is the part I think developers will appreciate, because the design is deliberately boring in the right places — it optimizes for speed while you work and safety when you save.

When you connect, DBGridy:

Pulls the file down over SFTP into a local cache (a private mirror keyed by the remote source). Your edits never hit the network on the hot path — they hit a local SQLite file, so the grid stays instant.
Opens the mirror as a normal SQLite database. Everything you already know works: multi-tab SQL editor with syntax highlighting, in-cell editing, add/delete rows, CREATE/DROP, the lot.

Then, the moment you change data — an in-cell edit, an inserted row, a deleted row, an UPDATE/INSERT/DELETE you ran in the query editor — DBGridy pushes the file back to the server automatically:

It runs a WAL checkpoint first when the database is in WAL mode, so the bytes you upload are the complete, consistent picture — not a main file with half the story still living in a -wal sidecar.
It uploads over SFTP and writes the remote file atomically (download/replace uses a temp file + retry, so a flaky connection won't leave you with a truncated database).
Rapid edits coalesce. If you fix five cells in two seconds, you don't get five competing uploads stepping on each other — an upload in flight simply schedules one more pass when it finishes, so the server always converges on your latest state.

And you get feedback the whole way. The log panel tells you exactly what's happening:

Info : Remote SQLite saving... (deploy@db.example.com:22:/var/lib/myapp/app.db)
Ok   : Remote SQLite saved to server: deploy@db.example.com:22:/var/lib/myapp/app.db

No "Save" button to forget. No "Sync" dialog to babysit. You edit; it's saved. The server file stays the single source of truth.

Good to know: Remote SQLite is built for the "one person fixing data on a server" workflow — the case you actually hit at 2 a.m. The remote copy is the canonical one, and your local mirror refreshes when you connect.

Why this matters

SQLite is everywhere now — edge deployments, IoT devices, self-hosted apps, CI artifacts, that one internal tool nobody wants to touch. It's a fantastic database precisely because it's just a file.

But "just a file" is also exactly why operating on it remotely has always been clumsy. The file lives over there; your tools live over here. DBGridy closes that gap so the remote file behaves like a local one, without you ever leaving the editor or thinking about transport.

DBGridy is more than one trick

Remote SQLite over SSH is the newest headline feature, but it lives inside a tool built to be the one grid editor for all your databases.

One UI, many databases. Connect to MySQL, PostgreSQL, SQL Server, Oracle, SQLite, MongoDB, Redis, and ClickHouse — SQL and NoSQL — through the same grid-based interface. Stop context-switching between five different clients.

A real query workspace. Syntax highlighting, multiple query tabs, a "Merge INSERT Statements" tool for bulk operations, and one-click export to CSV, SQL, or JSON.

A built-in SSH terminal. Full xterm.js emulation (256-color, vi/nano, mouse, clipboard), terminal tabs right next to your query editors, SFTP-aware "open terminal here," and sessions that survive a restart. WSL works too.

A developer utility belt. The Convert Util menu packs the stuff you'd otherwise keep a dozen browser tabs open for: Base64 / URL / UTF-8 encode-decode, Unix-timestamp ↔ UTC, JWT generate & decode, AES encrypt/decrypt, hashing, UUID generation, a JSONPath tester, and Hex ↔ Decimal.

Compare mode. Character-level diff highlighting (including whitespace), line-by-line copy between editors, and keyboard-driven diff navigation.

Light and dark themes, because your eyes matter at 2 a.m.

Try it

DBGridy is a Windows desktop app — download the release, unzip, run DBGridy.exe. No installer ceremony.

👉 dbgridy.com

If you maintain anything backed by a SQLite file on a remote box, give the SSH workflow a spin and tell me it isn't the part you didn't know you were missing. And if there's a database or a workflow you wish it handled, I'd genuinely like to hear it.

DEV Community