dbx vs DBeaver: The 25 MB Upstart and the Universal Veteran

Two database clients keep showing up in the same "which one should I use" threads: dbx, the 25 MB newcomer from github.com/t8y2/dbx, and DBeaver, the veteran that has been the default answer for over a decade.

dbx's own README makes the challenge in four words: "DBeaver needs Java." That captures the pitch, and it is also only half the story.

This post compares the two on the axes that actually decide the argument for most people: size and startup, what each covers out of the box, the AI story, how you deploy each, and what each costs. The short answer is that both are excellent and both are free; they just made different bets.

The short version

• dbx is the frictionless newcomer. A single ~25 MB binary, no Java runtime, no runtime installs. Download, install, connect, in the time it takes DBeaver to finish its first launch. Apache-2.0, and no paid edition listed today.
• DBeaver is the universal veteran. Free and open source (Community edition) since the early 2010s, built on Java, and able to connect to basically anything with a JDBC driver, which is nearly everything that ever shipped with a SQL interface. ODBC support lives in the paid editions.
• Their coverage overlaps, then diverges. dbx ships native support for Redis, MongoDB, DuckDB, ClickHouse and others in the free binary. DBeaver's free Community edition covers the same SQL side: DuckDB, ClickHouse and Elasticsearch are all in its out-of-the-box driver list. What sits behind the paywall are the true NoSQL stores (MongoDB, Redis, Cassandra, CouchDB) and ODBC.
• dbx wins on friction and speed. Size, startup, memory footprint, a built-in AI assistant, and an MCP server (a separate download) that AI coding agents can talk to directly, free.
• DBeaver wins on maturity and coverage depth. More than fifteen years of hardening, a feature set that keeps growing (ER diagrams, data transfer, execution plans, admin tools), and the answer to "what connects to this weird legacy database."
• The decision rule: choose dbx for a fast, modern, all-in-one client covering the engines people actually run today; choose DBeaver when compatibility with everything, including the exotic stuff, matters more than startup time. And since both are free, the honest move is often to run both.

What dbx actually is

dbx is a Tauri 2 app from t8y2/dbx with a Rust core and a Vue 3 UI rendered in the system webview, and its headline number is its whole personality: about 25 MB for the entire application, with no bundled Chromium, no Java runtime, no Python environment.

The README counts 100+ databases, including the usual suspects (MySQL, PostgreSQL, SQLite, SQL Server, Oracle, MariaDB) plus native support for Redis, MongoDB, DuckDB, ClickHouse, and a long tail of engines reachable through driver profiles (Snowflake, Trino, Hive, Cassandra, BigQuery, Databricks, SAP HANA and more).

The AI story is where dbx pulls ahead of the older crowd. There is a built-in SQL assistant: highlight a table, describe what you want in plain language, get SQL back, with safety checks reviewing AI-generated queries before they run. It works with Claude, OpenAI, or local models via Ollama.

Beyond the assistant sits an MCP server, distributed separately via npm or a standalone binary, which matters to anyone using AI coding agents. In plain terms: Claude Code, Cursor, Windsurf and similar agents can connect straight to the databases you configured in dbx, using the connections you already set up, instead of you pasting results between tools. DBeaver's world does have an answer here, but it lives in the commercial edition of dbvr, DBeaver's CLI, not in the free desktop app. The free dbvr Community explicitly excludes the MCP feature.

Deployment is another deliberate difference. dbx ships as a native app for macOS, Windows and Linux, plus a self-hosted Docker image that exposes the same feature set in the browser for team access, plus a CLI for scripts (the CLI is also its own package). The same connections follow you across all three. It also goes beyond SQL: message queues and middleware (Kafka, RabbitMQ, RocketMQ, Pulsar, MQTT, plus Nacos, Consul, ZooKeeper, etcd) have built-in consoles, and a plugin store adds S3, Kubernetes, LDAP and more.

One detail is worth its own paragraph for anyone switching: dbx imports connection profiles directly from DBeaver and Navicat, so the barrier to trying it is close to zero.

What DBeaver actually is

DBeaver (dbeaver.io) is the free, open-source database tool that has quietly become the industry default.

Community edition is Apache-2.0 licensed and recommended for personal projects; the project sells paid tiers under the DBeaver PRO umbrella (Lite, Enterprise, Ultimate, plus team and cloud editions) for organizations that need more. Its own pitch is the honest one: it supports any database that has a JDBC or ODBC driver, "basically - almost all existing databases." Read that carefully: in the free edition the promise runs through JDBC, which still covers more than a hundred drivers out of the box, among them DuckDB, ClickHouse, Elasticsearch, Snowflake and BigQuery. ODBC is one of the things you pay for. Either way, if a database predates your career, DBeaver probably still talks to it.

Over its fifteen-plus years the feature set has accumulated into a small universe: schema editor, SQL editor, data editor, ER diagrams, data export/import/migration, query execution plans, database administration tools, dashboards, a spatial data viewer, SSH tunneling, a custom driver editor, and an AI chat. The tool is famously deep and famously busy, and there is an answer in the docs or the community for almost any corner case you can hit. That is the real value of maturity: not the feature list, but the years of "someone already hit this and wrote it down."

The trade for that breadth is weight. DBeaver is a Java application whose standalone installer bundles the runtime; it is decisively heavier than dbx on disk, it is known to take a while to start, and users working with large schemas describe it as sluggish. That is the community's most common complaint, not a judgment on every machine. The other trade is tiering: Community is SQL-first, and NoSQL databases (MongoDB, Redis, Cassandra), ODBC connectivity, enterprise authentication (SAML, SSO, Kerberos) and cloud integrations sit in the paid editions.

At a glance

Where dbx wins

• Getting started is measured in minutes. A 25 MB download that launches fast and looks like a native app. The "DBeaver needs Java" line is marketing, but it points at a real gap: dbx does not ask you to accept a runtime first.
• AI is built in, not bolted on. The SQL assistant runs with cloud models or your local Ollama setup, and the MCP server (a separate download) gives coding agents direct access to your databases for free. With DBeaver, the equivalent sits in the commercial dbvr edition because the free dbvr Community CLI has no MCP, and the free AI chat only speaks OpenAI-compatible endpoints and Copilot. For anyone living in AI-assisted workflows, that is a category difference, not a feature checkbox.
• NoSQL and middleware are free and included. Redis, MongoDB, Elasticsearch and the queue consoles live in the same binary that costs nothing. DBeaver's Community actually covers DuckDB, ClickHouse and Elasticsearch too. What it gates behind paid editions are the document and key-value stores (MongoDB, Redis, Cassandra, CouchDB) and ODBC.
• One product, three deployment modes. Desktop for you, Docker for the team, CLI for scripts, with the same connections everywhere. DBeaver covers the same ground with separate products, namely the open-source CloudBeaver web app and the dbvr CLI, so it can be done, but each is its own install with its own configuration.
• It is young and modern. Native UI, dark mode, several editor themes, designed around how developers work today rather than how they worked in 2012.

Where DBeaver wins

• It connects to nearly everything. JDBC coverage in the free Community edition is enormous, with more than a hundred drivers out of the box, and the paid editions add ODBC on top: the exotic, the legacy, the vendor-specific, the "is anyone still running this?" databases. If compatibility is your job, DBeaver is the safe answer, and it has been for years.
• The maturity of its professional tooling. ER diagrams, data transfer and migration between engines, execution plans, admin dashboards, SSH tunneling, custom drivers. dbx's README now checks most of the same boxes, so this is no longer about missing features. It is about depth. In DBeaver these corners have been ground smooth by years of daily production abuse.
• Maturity is a feature. More than fifteen years of releases, a huge install base, answers to almost every error you will ever see, and predictable behavior on a work machine instead of a moving target.
• Enterprise readiness in the paid tiers. SAML, SSO, Kerberos, NoSQL, cloud storage, team task management, and commercial support when you need a contract behind the tool.
• It is everywhere. You have met DBeaver at every job; your muscle memory and your colleagues' both transfer, and the documentation and community answers are worth more than they look.

The limits that bite

• dbx is fast, and fast-moving. More than 7,500 commits in its first five months, rapid releases, and a young codebase. Interestingly, its open issue tracker is actually smaller than DBeaver's 3,000-plus open issues. But age, not issue count, is the real risk: fewer ready answers when you hit a corner case, and the tool can change under you between releases. Pin versions and track updates.
• dbx's deepest reach runs through driver profiles. Native coverage for the common engines is excellent; for the exotic tail (Snowflake, Hive, Cassandra, BigQuery) you are trusting JDBC agent profiles rather than a twenty-year compatibility promise, and depending on the profile, a local JVM may be quietly back in the picture. "No Java" is true for dbx's native drivers, not automatically for every engine it can reach.
• DBeaver is heavy in the ways its users complain about. Java runtime, slow cold starts, and sluggishness on very large schemas, plus a UI that a generation of users describes as dated. Browsing a big production schema is where the weight shows.
• DBeaver's free tier stops at SQL. The moment you need MongoDB, Redis, Cassandra or an ODBC connection, you are in a pricing conversation. dbx is free everywhere today, which is the one thing a paid tier cannot undo.

Which should you pick?

• Choose dbx when you want one small fast client for the engines people run today, you want AI assistance and AI-agent access without configuration theater, you self-host and would like web access for the team, or you want Redis, MongoDB and message queues without a license meeting.
• Choose DBeaver when you live with legacy and exotic databases, you need the deepest SQL and administration workflows, you want a tool with a decade and a half of answers and enterprise credentials, or you need SSO and support contracts.
• The honest mixed answer: run both. Both are free, so the cost of a second client is disk space and an afternoon. Use dbx for the daily fast path and the AI work, keep DBeaver for the weird database and the deep tooling, and let your connections export straight across.

Official sources

• dbx repository: https://github.com/t8y2/dbx
• dbx website: https://dbxio.com
• DBeaver Community: https://dbeaver.io
• DBeaver GitHub: https://github.com/dbeaver/dbeaver
• DBeaver about and license: https://dbeaver.io/about/
• DBeaver PRO editions: https://dbeaver.com/edition/
• dbvr CLI (Community): https://github.com/dbeaver/dbvr
• dbvr MCP documentation: https://dbeaver.com/docs/dbvr/mcp-start/
• Our lightweight server tools comparison: https://systhoughts.com/posts/beszel-vs-dockhand-lightweight-server-monitoring
• Our local AI models post: https://systhoughts.com/posts/lm-studio-vs-ollama-vs-anythingllm-vs-unsloth-studio
• Our release tracking workflow: https://systhoughts.com/posts/tracking-software-releases-across-forges

Are you on Team DBeaver, Team dbx, or running both? What pushed you to switch or to stay? Drop it in the comments.

Until next time, keep your systems thoughtful.