ShayanAbbas1/dbdelve

A credible alternative for developers whose current Electron or JVM database client feels heavy, provided they can live with an un-notarized macOS build and an early-stage feature set.

The problem

You want to open a connection, run a query, page through a large result grid and tweak a cell without waiting on a slow launch or watching memory climb. Conventional clients bundle a browser runtime or a JVM, so the app stays resident in memory all day; on a large table the grid can stall or impose a row cap. DBDelve replaces that stack with a native Rust/GPUI application, so launching, scrolling and editing happen inside a lighter process. The result is a client that opens in about a second and keeps a million-row result navigable, as shown in the project's scrolling demo.

What's different

The central mechanism is GPUI rendering plus a native database layer, with no Electron or JVM. The author's own benchmark table (2016-10-11, M1 Pro, 32 GB, DBDelve 0.3.6 against DBeaver 25.3.1, median of five runs) claims 1.1 s versus 5.2 s launch, 133 MB versus 606 MB idle memory, and 56 s versus 208 s for one million rows with the row limit disabled — at 4.9 GB versus 17 GB. These are single-machine figures from the project itself, not an independent test, and the 1M-row case deliberately pulls the whole table into memory, so treat them as a comparison of the author's setup rather than a general promise.

Breadth is the second differentiator: Postgres, MySQL, MariaDB, SQLite, Turso, DuckDB, Snowflake, SQL Server, MongoDB and Redis/Valkey/KeyDB/Dragonfly sit behind one interface. Practical touches reduce friction when moving in: importing saved connections (including passwords and SSH settings) from DBeaver or TablePlus, and dropping a CSV, Excel, Parquet or JSON file to open it in an in-memory DuckDB session. The trade-off is depth: this is a young project whose README promises "complete parity" later, so engine-specific tooling and admin features that mature clients accumulate may be thin. Destructive actions prompt first, and each connection can be set to read-only, read-write or full access with a title-bar color, but that is a guardrail rather than a substitute for checking which environment you are pointed at.

Who should try it

Good fit: a developer who runs several database engines and mostly reads, filters and lightly edits data, and who resents a heavyweight client sitting in memory. The SSH-tunnel design — delegating to your own ssh so config, agent and hardware keys carry over — matters for anyone connecting through a bastion. Also a reasonable fit for someone who wants a free client with no paywalled features.

Poor fit: a team that depends on vendor-specific administration, or on a notarized macOS binary, since the install path explicitly requires clearing the quarantine flag. Anyone whose daily work is deep schema migration or tuning should check whether the relevant engine features exist before switching.

Requirements and limitations

Platform support is explicit: macOS 12+ on Apple Silicon only (no Intel build listed), Linux x86_64/aarch64 via AUR, tarball or AppImage, and Windows x86_64 via a zip. The macOS cask is not notarized, so the install instructions require a second command to clear the quarantine attribute; skipping it leaves the app unopenable. Linux has its own listed requirements, and building from source is a separate path. Updating and where data lives are documented in the same file, so ongoing upkeep is a documented concern rather than an unknown.

Feature limitations follow from age: more engines are "planned," and the project describes itself as early days. Connection imports are limited to DBeaver, plus TablePlus on macOS — other clients would need manual re-entry. The only unsolicited network request is an update check, which can be disabled.

HotRepo's take

The repository is 70 days old and recorded one day on the daily trending board, on 2026-10-27, at 549 stars with +27 that day. That is one dated snapshot, not a trend line; with no comparable history, persistence of interest cannot yet be judged. The benchmark claim is the concrete thing worth verifying for your own engine and table sizes, ideally against the published method before trusting the numbers.