22,000 Stars, a '25 MB' Badge and 443 MB of Java Agents: Auditing the DBX Database Client

There is a database client called DBX that has been impossible to miss since the spring. Its GitHub repository describes itself as “25 MB lightweight cross-platform database client for 100+ databases”. Its website, at the top of the page, says “25 MB to manage 100+ databases!”. It has 21,998 stars, 2,087 forks and 306 releases in 154 days — two per day.

I have spent this audit doing one thing: reading the objects the project actually ships. Not the README, not the badges — the installers, the container image, the machine-readable driver manifest the application itself downloads at runtime, the release notes and the authentication middleware. Most of the numbers below are reproducible in an afternoon by anyone with curl and a GitHub token. That is the point: none of them require privileged access or a source-code review, and several of them contradict the top of the funnel.

The summary version: DBX is a genuinely interesting, well-engineered Tauri application with an unusually honest changelog and a critical security bug in its recent past. It is also wrapped in a claim stack that its own artifacts do not support, and a download counter that is 80% machine traffic. Both things are true at once, and the second one matters if you are choosing a tool for a team.

The claim stack, checked

What “25 MB” actually describes

The number is not invented — it is just doing a lot of work. Downloading the v0.6.28 .deb (41,109,138 bytes) and unpacking it gives a single payload binary, /usr/bin/dbx, of 88,861,984 bytes (84.74 MiB), with the package’s own metadata declaring an Installed-Size of 86,905 KB. The .deb is 39.20 MiB on the wire because it compresses well; the thing on your disk is more than three times the advertised figure.

Here is the full desktop picture for the current release:

Exactly one of those is 25 MB. Two useful things follow from the table. The first is that the Windows-on-ARM installer of the day happens to sit at 25.70 MB decimal / 24.51 MiB, so the headline is not a lie so much as a selection: it is the minimum over the 33 assets v0.6.28 published, presented as the size of the product. The second is that when the website says “~25 MB desktop installer”, the qualifier is doing real work, and the moment you leave Windows you leave the qualifier behind.

The offline variants are where the honest scale shows up. Windows 10/11 “intranet” packages are shipped at 173.46 MiB and 231.75 MiB because they fold in the WebView2 runtime, and the release train also carries dbx-agents-offline-windows-x64.zip at 661.02 MB, dbx-agents-offline-macos-x64.zip at 663.7 MB and dbx-agents-offline-macos-aarch64.zip at 658.9 MB. Those are not the app. They are the driver pack.

The number has drifted, on the same page

This is the part that made me stop trusting the headline rather than just qualifying it. The official English site, on one single page, currently carries all of the following:

• Page title and hero: “25 MB to manage 100+ databases!”
• Stat card: “~25 MB desktop installer”
• Testimonial (Zhihu, June 2026): “A 15MB package that packs in 40+ databases…”
• Testimonial (Medium, May 2026): “The 15 MB figure isn’t hype. Tauri 2 doesn’t embed Chromium…”
• Testimonial (xiaoz.org, May 2026): “a powerful open-source tool under 20MB”
• Testimonial (X post, August 2026): “an open-source tool that’s only 20MB, yet it packs in 80+ databases”
• Testimonial (HelloGitHub, featured issue #122): “supports over 40 databases”

So the size claim moves between 15, 20 and 25 MB, and the engine count between 40+, 80+ and 100+, without any of these numbers being marked as historical. The author’s own launch post on DEV Community, from 2 May 2026, is titled “DBX: An Open-Source, 15 MB Database Client for 17+ Databases (Built with Tauri)” and says “the installer is only ~15 MB”. An independent review published on 16 July 2026 by Oleksandr Korol describes “more than 60 databases while keeping the application at around 20 MB”.

That is a six-month drift from 15 MB/17 engines to 25 MB/100 engines, with a dozen intermediate numbers, and every one of them still displayed as current marketing. Nothing here is fraud — the product really did grow both smaller-in-marketing and larger-in-capability — but a number that can be any of {15, 20, 25} depending on which paragraph you read is not a specification. It is a slogan.

For calibration, the comparison the README actually makes is fair. DBeaver Community 26.2.1 ships a 121.1 MB Linux .deb, a 117.0 MB macOS ARM disk image and a 111.2 MB Windows installer. DBX’s 39.20 MiB .deb really is roughly a third of that, and Tauri genuinely avoids bundling Chromium: the .deb depends on the system libwebkit2gtk-4.1-0, libgtk-3-0 and libappindicator3-1. “About a third of a DBeaver download” is defensible, checkable and boring. “25 MB” is none of those things.

100 databases, decomposed

“100+” turns out to be exactly 100 in the marquee on the project’s own site, and the list is worth reading as a set rather than a count:

• 9 entries are not databases at all. Etcd, ZooKeeper, Pulsar, Kafka, RocketMQ, RabbitMQ, MQTT, Nacos and Consul are message queues and service-discovery/config stores. DBX gives them first-class consoles, which is a real feature — but counting them raises a “database engines” figure.
• 2 entries are version variants of another entry. “Ignite 3” and “InfluxDB 3” are counted separately from Ignite and InfluxDB.
• 1 entry is a product alias. InterSystems Caché and InterSystems IRIS are the same product line, listed twice.
• 1 entry is a protocol, not a product. “JDBC” is the catch-all for anything with a Java driver.

Remove those and the “100+ database engines” claim is 87 distinct data engines — still an extraordinary number, and still far more than any Western GUI client covers out of the box. The composition is the interesting part: 27 of the 100 names are Chinese-market engines (Dameng, openGauss, GaussDB, KingbaseES, OceanBase, TDSQL, PolarDB, GreatSQL, GoldenDB, YashanDB, GBase, XuguDB, Vastbase, UXDB, HighGo, SelectDB, Doris, TDengine, KWDB, ArgoDB, Transwarp Inceptor, Kylin, OSCAR, SunDB, Kyuubi, Cloudberry, OpenTenBase) — 29 if you count TiDB and StarRocks. No Western database client comes close to that coverage, and it is the clearest signal of who DBX is actually built for.

Seven native drivers, 54 Java agents

The README’s phrase “Agent-based profiles extend DBX to H2, Snowflake, Trino…” is doing more work than it appears to. In the repository there are exactly seven native Rust driver crates: dbx-driver-mysql, -postgres, -redis, -mongodb, -elasticsearch, -sqlserver and -sqlite-worker. Everything else goes through agents/, which contains 53 driver directories (Java and Go) and produces a separate release train.

The application’s own runtime manifest makes the dependency explicit. agent-registry.json — a 57,350-byte file attached to the agents-v0.2.125 release, which the app fetches to know what to download — has two top-level keys: jres and drivers. It lists 54 drivers, and all 54 declare "jre": "21". None is runtime-free. The same file pins the runtime: a custom OpenJDK build, 21.0.12+kerberos.ec.2, distributed per platform at 30.5 MB (Windows ARM64) to 34.8 MB (Linux x64).

Add up the 54 agent packages and you get 408.1 MB; add one JRE and the full “100+ databases” capability costs 443.0 MB of on-demand downloads on top of the 84.74 MiB main binary. The heavy end of the list is instructive:

Two conclusions, and I want to be fair about both. First, the architecture is defensible: shipping a 34.8 MB JRE and a 67.9 MB Snowflake agent to every user, whether or not they ever open Snowflake, would be worse. Downloading it on demand is the right call, and DBX’s registry is unusually transparent about it — you can read the manifest before you trust it, complete with SHA-256 hashes. Second, the marketing sentence “No Java JRE. No Python venv. No bundled Chromium. DBX ships as a single small binary” is not true of the product. It is true of the installer, and only for the seven native engines. For the Docker distribution it is not even true of the installer: deploy/Dockerfile installs openjdk-17-jre-headless and sets DBX_JAVA_BIN=/usr/bin/java.

So “lightweight” here means “small until you use it”. For a MySQL/PostgreSQL/Redis daily driver, DBX weighs what it says. For a Snowflake-plus-Kafka user, the real number is closer to half a gigabyte of runtimes fetched after installation, and if you have to work offline, that is why the 661 MB agent bundles exist.

The security chapter: CVE-2026-55642

On 20 August 2026, with GitHub acting as the CNA, a critical vulnerability was published for DBX: CVE-2026-55642, CVSS 3.1 9.8, CWE-306 (missing authentication for a critical function). The affected range is everything before 0.5.51.

The mechanism is described in the advisory and matches the public code. In crates/dbx-web/src/auth.rs, the auth_middleware passed every protected request through to the handler chain whenever password_hash was None. A fresh deployment reaches exactly that state when DBX_PASSWORD is unset and no password has been stored yet, and crates/dbx-web/src/main.rs bound the service to all interfaces on port 4224 by default. The result: an unauthenticated network client could call /api/connection/connect and /api/query/execute and run arbitrary SQL using the database credentials DBX had already been given. The desktop application was not affected, because it binds to loopback only.

The two things a prospective user should notice are the shape of the bug and the shape of the disclosure. The bug is not a memory-safety accident; it is a fail-open default in an authentication check — missing configuration was treated as a reason to skip authentication rather than a reason to refuse to serve. Fail-open auth is the single most common way self-hosted developer tools get compromised, and the fix is the textbook one: refuse.

Disclosure was also split in an interesting way. The fix shipped in v0.5.51 on 8 July 2026, and its release notes describe it in Chinese as a web-MCP correction — “Web 部署的 MCP 调用现在需要认证，避免未授权访问”, credited to a contributor, closing issue #2887. No CVE, no advisory, and no security framing in the changelog at that point. The CVE and GHSA-rqp4-8fxh-22vh appeared six weeks later, on 20 August. Defenders running a fork of the July release notes would have had no signal on 8 July that anything security-relevant had happened.

I read the current auth.rs on main to check what a fresh deployment does today, and the fix is real and reasonably thorough. Only auth/login, auth/setup and auth/check are reachable without a session; everything else returns 401 while password_hash is None, with an explicit setup_required response from login. Passwords are stored as Argon2 hashes, logins are rate-limited (five attempts, then a 60-second lockout), sessions are HttpOnly; SameSite=Lax cookies with Secure opt-in via DBX_WEB_COOKIE_SECURE=1, and change-password requires a session so it cannot be used as an unauthenticated password oracle.

Two caveats survive the fix. The web service still defaults to binding on all interfaces — the comment in main.rs says so explicitly, offering DBX_BIND_ADDR=127.0.0.1 for operators who front it with a local reverse proxy — and the shipped deploy/docker-compose.release.yml publishes 4224:4224 with no password variable set, which is fine only because a fresh instance now refuses everything until you complete setup. And DBX_PASSWORD unset is still the default state on first boot; there is nothing in the compose file to tell you that.

If you self-host DBX today, the minimum set is: pin a release ≥ 0.6.28; set DBX_PASSWORD before first start; set DBX_BIND_ADDR=127.0.0.1 unless you have an authenticating reverse proxy; back up ${DBX_DATA_DIR}/.dbx/secret.key with dbx.db (the docs are explicit that the key cannot be rotated while encrypted data is in use, and that a bare dbx.db copy is not portable because platform keys do not travel); and give it least-privilege database accounts. Later releases added further hardening worth having: same-origin validation on the Redis pub/sub WebSocket upgrade, unsigned plugins rejected by default, and password changes that invalidate all live sessions.

The download badge is 80% updater pings

The README displays a downloads badge showing 2.8m. Here is what that number is made of. Reading GitHub’s own per-asset counters across every one of the 306 releases from 2026-04-29 to 2026-09-29 gives 2,783,550 total asset downloads — which is where 2.8m comes from. Of that total, 2,237,662 (80.4%) are latest.json, the Tauri auto-updater manifest: an 18.4 KB machine file that every installed copy of the app fetches to check for updates. The repository even vendors tauri-plugin-updater in-tree, so there is no ambiguity about the mechanism.

Actual artifact downloads: 545,888 across the entire history of the project, and that still counts .sig files, .sha256 sidecars, and each new version’s full set of platform installers, which long-lived installs re-download on every update.

The per-asset ranking is the most revealing thing in this audit:

Two things fall out. The single most-downloaded real artifact in the entire project is the JDBC plugin — the very component the website says DBX does not need (“Native Rust drivers, no JDBC runtime”). And the JRE tarball outranks every individual app installer except the newest one or two, which is a hard, empirical confirmation of what the registry implied: the Java agent path is not an edge case, it is the workhorse.

There is also a vendor disagreement worth knowing about. For the same repository and the same metric, shields.io currently reports 798k where the badge in the README reports 2.8m — a 3.5x spread between two “downloads” badges. I could not reproduce 798k from the GitHub API no matter how I sliced it, and shields.io’s latest-release figure (6.3k) does match GitHub’s counter for v0.6.28 (6,343 at the time of writing), so the discrepancy is specific to the total. I do not know which vendor is “wrong”; what I can say is that a metric that three providers report as 798k, 2.8m and 545k-real is not a metric to quote in a procurement document.

If you want an actual installed-base estimate, do not use any of those numbers. Use the manifest counter for the newest release: v0.6.28’s latest.json had been fetched 5,231 times within roughly eight hours of publication, while its Windows x64 installer had been fetched 435 times. Whatever the true population is, the update-check channel is an order of magnitude busier than the download channel — which is what you would expect from a fleet of existing installs polling, not from 2.8 million people trying DBX.

832 Homebrew installs versus 21,998 stars

Star counts are the least reliable adoption signal in open source, so here is a measurement that is not a star count. Homebrew publishes anonymised installation analytics, and for the 30-day window from 2026-08-30 to 2026-09-29 (9,743 casks, 1,098,246 recorded install events) the database clients rank like this:

DBX is a top-2% Homebrew cask (rank 196 of 9,743), which is genuinely good for a five-month-old project and not the story its star count tells. Compare the two ratios: DBX has 42.4% of DBeaver’s stars (21,998 vs 51,922) and 15.9% of its macOS installs. Its star-to-install ratio is roughly 2.7x DBeaver’s. That gap is the normal shape of a project that trended on GitHub in China in August (Trendshift records #2 on GitHub Trending, plus repository-of-the-day/week/month badges) — stars are a discovery metric, not an adoption metric, and DBX is a textbook case.

The rest of the ecosystem picture is mixed but mostly better than the badge numbers suggest:

• Docker Hub: 152,059 pulls for t8y2/dbx, and 2 stars. The pulls are real; the 138.42 MiB image is also real.
• npm (last 30 days): @dbx-app/mcp-server 42,185; @dbx-app/plugin-cli 5,241; @dbx-app/cli 4,646. npm counts include CI and mirrors, so treat as an upper bound — but the MCP server being the most-installed package is consistent with the feature the reviews actually praise.
• Homebrew, WinGet, AUR: all present. The Homebrew cask is autobump-enabled and in the official homebrew/cask tap; t8y2.DBX exists in microsoft/winget-pkgs with version directories up to 0.6.28. This is better packaging coverage than most projects twice its age.
• Flathub: absent. com.dbxio.dbx returns “App not found” from Flathub’s API. The README instead tells Linux users to add a third-party remote called FlatPark (dl.flatpark.org, self-described as “Yet another Flatpak hub”), which means the install instruction points users at a non-standard package source for a tool that will hold their production database credentials.
• AUR: two packages, dbx and dbx-bin. The latter declares its licence as MIT while the upstream project is Apache-2.0. Third-party packaging errors are common, but a wrong licence field on a package most Arch users will install from is worth knowing about.

306 releases in 154 days

Between 2026-04-29 (repository creation) and 2026-09-29 the project published 306 releases — 1.99 per day. They arrive on three trains: the desktop app (v0.6.x, 31–33 assets per version), the Java/Go agents (agents-v0.2.x, 146–153 assets per version, most days) and the CLI/MCP packages (packages-v0.4.x, 14 assets). The app itself went from v0.6.20 on 22 September to v0.6.28 on 29 September: nine versions in eight days.

This velocity is the project’s best and worst property. It is why DBX covers 87 engines and fixes things within days; it is also why “pin a version” is not optional, why the 306 release bodies are the only reliable changelog, and why the security fix above could ship as a one-line bullet in a 3,233-character Chinese release note. If you deploy this in a team, budget for reading release notes, not for stability.

Who this is built for

Follow the money and the community links and the picture is unambiguous. The website’s root serves Chinese (zh-CN); the English site is the translation. Community links are QQ groups, WeChat and Feishu, plus Discord. Docker pulls are mirrored to docker.cnb.cool/dbxio.com/dbx for users inside China. The README carries eight sponsor cards and two partner cards, most with referral links: RainYun, TrustAsia (which signs the Windows builds), Jalapeño Cloud, AICodeMirror, HuaLongAI, UCloud’s AstraFlow, Atlas Cloud, Qiniu Cloud, plus the 1Panel and Easysearch integrations.

One of those deserves a flag. The AICodeMirror sponsor card advertises relayed access to Claude Code / Codex / Gemini at “as low as 38% / 2% / 9% of list price”. Selling discounted resold API access to first-party AI coding subscriptions is a well-known grey zone, and it is a sponsorship — not a technical dependency. But it is now a row in the README of a tool you would point at your production databases, and readers should weigh that the same way they would weigh an ad for a VPN in a security tool’s repository.

None of this makes DBX a bad tool. It makes it a China-first product with an English-facing GitHub page, which explains both its engine list (27+ Chinese databases no Western client supports) and its community structure. If you work with Dameng, openGauss, KingbaseES or OceanBase, DBX’s competition is not DBeaver — it is a paid local tool.

What is genuinely good here

An audit that only counts problems is not an audit, and this project has real engineering in it that the marketing does not deserve to overshadow:

• Tauri 2, no bundled Chromium — verified. The .deb depends on the system libwebkit2gtk-4.1-0; there is no Electron-shaped payload. This is a real architectural win over most of its competition.
• Apache-2.0, with a plugin store that publishes its security infrastructure. t8y2/dbx-store ships signing-keys.json, revoked.json, a publishers directory, JSON schemas, and a SECURITY.md; v0.6.28 went further and rejects unsigned plugins by default.
• Signed, checksummed releases. Every artifact has a SHA-256, several have detached .sig signatures, and the Windows builds go through a code-signing provider announced as a sponsor.
• The agent registry is public and machine-readable. Being able to read exactly which JRE build and which agent JAR version you are about to download is more transparency than most clients offer.
• A real, detailed changelog. 306 release notes with contributor attributions and linked PRs; the v0.6.28 notes credit 10+ outside contributors by name.
• Broad, shallow-tolerant engine coverage. 87 distinct engines, including time-series, vector and search systems, plus message queues and service discovery in the same window.
• The MCP server is a separate binary in a separate package (@dbx-app/mcp-server, Rust, precompiled for five platforms, no Node required) with a read-only / safe-write / full-access policy model. The README states plainly that installing the app does not install the MCP executable, and warns that Windows portable builds need DBX_DATA_DIR — honest documentation of an awkward edge.
• 305+ contributors and a plugin SDK. Whatever else is true, this is not a one-person show with a marketing budget.

Practical decision table

FAQ

Is the “25 MB” claim false? It is not false, it is the minimum. Of the 33 assets in v0.6.28, the Windows-on-ARM installer is 24.51 MiB (25.70 MB) — the only one that rounds to 25 MB. Windows x64 is 26.74 MiB, the Linux .deb installs to 84.87 MiB, the AppImage is 110.68 MiB and the Docker image is 138.42 MiB. The website qualifies it as “~25 MB desktop installer”.

Does DBX really need no Java? For its seven native Rust drivers, yes. For everything else, no: agent-registry.json lists 54 drivers that all require a custom OpenJDK 21.0.12+kerberos.ec.2 (30.5–34.8 MB per platform), and the 54 agent packages total 408.1 MB. The Docker image installs openjdk-17-jre-headless outright. The design — fetch on demand rather than bundle — is reasonable; the sentence “No Java JRE” is not.

How many databases does “100+” mean? The site’s own marquee lists exactly 100 names. Nine are message queues or service-discovery systems, two are version variants, one is a product alias and one is the JDBC catch-all, which leaves 87 distinct data engines — 27 of them Chinese-market engines.

Am I affected by CVE-2026-55642? Only if you exposed dbx-web/Docker before version 0.5.51 with no password configured, and only if that port was reachable by untrusted clients. The fix has been in since 8 July 2026 and the current code fails closed. Check whether you ever ran an older image with 4224:4224 published to the internet.

Why does the downloads badge say 2.8m? Because it counts every asset download, and 80.4% of those are the latest.json auto-updater manifest. Real artifact downloads across 306 releases total 545,888, and the most-downloaded real artifact is the JDBC plugin at 21,188.

Is it really open source? Yes — Apache-2.0, with the plugin catalog, signing keys and revocation list public, unsigned plugins rejected by default, and signed releases. The caveats are packaging-level (not on Flathub; the AUR dbx-bin package mislabels the licence as MIT) rather than licensing-level.

The verdict

DBX is a real product with a real audience: 87 engines with serious Chinese-database coverage, a Tauri architecture that is genuinely lighter than its rivals, a public agent registry, signed builds, an honest 306-release changelog, and contributors numbering in the hundreds. If you work with the engines it covers and you accept its update velocity, it does something DBeaver does not do at any price.

What it also has is a marketing stack that no longer touches the artifact. The headline size describes one installer on one architecture; the engine count includes message queues, duplicate product names and a protocol; the “no Java” line survives by pointing at the seven native crates while the app quietly downloads a 34.8 MB custom JVM and 408 MB of agents; and the download badge is four-fifths machine traffic. And one release train — the one that talks to your production databases over HTTP — carried a CVSS 9.8 fail-open authentication bug that was patched competently in July and only became a CVE in August.

Use it, pin it, set the password, bind it to loopback — and read the numbers from the artifacts, not from the badge row.

Methodology

All figures were measured on 2026-09-30 UTC. Artifact sizes and download counters come from GitHub’s release API across all 306 releases of t8y2/dbx; the driver-and-JRE inventory from the agent-registry.json asset of release agents-v0.2.125; the installed size from downloading DBX_0.6.28_amd64.deb (41,109,138 bytes) and unpacking it with dpkg-deb; the engine breakdown from the project’s own English site, de-duplicated; adoption figures from Homebrew’s cask analytics for 2026-08-30 to 2026-09-29, the Docker Hub API, npm’s downloads API and the AUR RPC; the vulnerability details from the MITRE CVE record and OSV for CVE-2026-55642; and the authentication behaviour from reading crates/dbx-web/src/auth.rs and main.rs on main plus deploy/Dockerfile and deploy/docker-compose.release.yml. Where a number is an inference rather than a measurement — the installed-base estimate, for instance — the text says so.