Every database in one native app. Free and open source.

Why datagrep

Like DataGrip, but free and light

Most database clients make you choose: a heavyweight IDE, an Electron app, or one tool per engine. datagrep’s bet is different — one small native app where relational rows and documents are equals.

A trust surface, not cosmetics

NULL is not "" is not absent

In a document store a field can be missing entirely — a third fact, distinct from NULL and from an empty string. Most clients collapse all three into one blank cell; our competitor study found none that cleanly distinguishes all three, and several with shipped bugs here — an invisible NULL label in dark mode, NULL exported as the literal string "null". datagrep renders each one distinctly, in the grid and in the CLI.

The honest comparison

How it stacks up

Every claim about a competitor below traces to a cited source in our UX reference study — GitHub issues, official docs, or the vendor’s own pages. Where the study found nothing, the cell says so. And where a competitor is ahead of us, the table says that too.

To be plain about where datagrep is behind: every tool in this table has inline cell editing today, and most have autocomplete — datagrep has neither yet. If you edit rows in a grid all day, those tools currently serve you better. What datagrep already does better is the part they routinely get wrong at scale: streaming large results with flat memory, staying responsive against huge schemas, and telling you the truth about blank cells.

Engines

What connects today

One driver crate per engine, behind a capability-based API — no engine ever gets special-cased above the driver seam.

The app is macOS today, and it reaches all six engines; a native Linux app (Qt6/C++) over the same Rust engine is in progress. The CLI currently registers PostgreSQL and SQLite only — Redis, MongoDB, MySQL / MariaDB and Elasticsearch surface through the app.

Install

Download, or build from source

Each release ships datagrep-macos.dmg — open it and drag datagrep.app onto the Applications shortcut. The installer script does the same thing, and also installs the CLI:

curl -fsSL https://raw.githubusercontent.com/chud-lori/datagrep/main/install.sh | bash
# → the CLI; add `-s -- --app` to install the app too

xattr -dr com.apple.quarantine /Applications/datagrep.app

Uninstall

The same script removes what it installed — the CLI on its own, or the app as well with --app.

curl -fsSL https://raw.githubusercontent.com/chud-lori/datagrep/main/install.sh | bash -s -- --uninstall
# add --app to remove datagrep.app too

Uninstalling deliberately leaves your data alone, so a reinstall finds your connections, query history and saved editors where you left them. To remove those as well, delete ~/Library/Application Support/datagrep and ~/.config/datagrep. Saved passwords live in the login keychain under the service datagrep and go with the connection that owns them.

Build from source

Two commands, two artifacts. The macOS app needs no Xcode — the Command Line Tools are enough, because it builds with Swift Package Manager rather than xcodebuild.

cargo build --release
# → target/release/datagrep

cd ui/macos && ./build-app.sh
# → ui/macos/datagrep.app

Prerequisites: a Rust toolchain (see rust-toolchain.toml) and the macOS Command Line Tools (xcode-select --install). cargo test --workspace runs everything that needs no live server.

The CLI

The same engine, in your terminal

Connections are named profiles. A password in a connection URL is moved to the OS keychain on import — profiles store only a reference to it, never the secret.

$ datagrep profiles add local "sqlite:///tmp/app.db"
created profile `local` (sqlite)

$ datagrep query --profile local -c "SELECT id, name, note FROM users ORDER BY id"
id  | name  | note
----+-------+----------
1   | alice | NULL
2   | bob   |
3   | carol | likes SQL
(3 rows)

$ datagrep export --profile local -c "SELECT * FROM events" --format csv -o events.csv
$ datagrep query --profile prod -f report.sql --format json | jq '.[].email'

NULL (row 1) renders differently from an empty string (row 2) — the same three-way distinction the app’s grid makes.

query

run SQL (or a Mongo/Redis command) and stream results in table, csv, json, ndjson formats

export

write a full result set to a file

profiles

add, list, show, import/export named connections

catalog

browse databases, schemas, and tables

history

list past queries, with full-text search

doctor

check connectivity and configuration

Block directives

Any statement can carry per-block settings as plain comments — they travel with the query text, so they survive copy-paste and version control. The status bar shows what’s in effect.

-- @limit 200          cap the rows this block returns
-- @timeout 30s        give up after 30 seconds
-- @connection staging run against another profile
-- @readonly           refuse writes, checked client-side
SELECT * FROM events;

In the app, ⌘↵ runs the statement under the caret — never the whole buffer by accident.

Under the hood

How it stays small

The goal, in one line: the client you don’t have to close to get your laptop back. Three design decisions get it there.

Security

What’s defended — and what isn’t

A database client holds live credentials, opens connections to production systems, and renders whatever those systems send back. So datagrep has a written threat model that treats three inputs as attacker-controlled — the server, the connection URL, and an imported profile bundle. The claims below are the checkable kind: each one points at the code or policy file that makes it true.

The gaps, stated plainly

• PostgreSQL and MySQL connections are not encrypted. The Postgres driver implements no TLS, and the MySQL driver compiles it out. Both fail loudly — an sslmode=require URL is rejected, never silently downgraded to plaintext — but the consequence stands: across an untrusted network, use the built-in SSH tunnel. That is the supported answer until the drivers grow TLS.
• A profile bundle is executable. A profile’s secret can be an exec: command, and import does not gate that yet. Treat a bundle you did not write exactly as you would treat a shell script from the same source: read it before importing it.
• No external audit, one maintainer, ad-hoc code signing. datagrep is pre-1.0 and not notarized — this page says so rather than implying otherwise.

The full threat model, what “out of scope” means here, and the coordinated-disclosure process are in SECURITY.md. Found something? Use private vulnerability reporting — a human reads it within three business days.

The honest part

What’s not built yet

You’ll find these gaps eventually; better you hear them here first. If one of them is your daily driver requirement, datagrep isn’t your tool yet.

• No inline cell editing. Every competitor in the table above has it. The plan is a staged-edit, review-before-commit model — because a naive implementation can update the wrong row, and that’s worse than not shipping it.
• No autocomplete. Planned as a restrained, lazily indexed version — our study found a bad autocomplete generates more anger than none.
• Elasticsearch is read-only — browsing and querying work, writes are not implemented.
• App-side gaps: no export UI (the CLI has export), no foreign-key click-through, no ER diagrams.
• macOS only. No Linux or Windows app today.

Something else missing, or broken? File an issue — engineering notes, test reports, and the full competitor study live in notes/.