Decide which saved connections an agent should reach
DBX's separate MCP server can expose connections configured in the application to coding agents. Before adding a production profile, decide which connections the agent should see and which operations its database credentials should permit.
The DBX README describes desktop and web interfaces, query history, schema browsing, editable results and an AI SQL assistant. These are documented reasons to evaluate the client. Our sandbox run did not verify database compatibility, generated-query correctness or agent permissions.
What happened when we ran it
Our sandbox installed dependencies in 23 seconds and completed the build in 32 seconds at commit d4b4cf8 on October 3, 2026. It recorded 756 dependencies occupying 631 MB. The checkout contained 6,091 files, roughly 1,798,126 source lines and 197.1 MB of data. Those are source-workspace measurements, not desktop download sizes.
The test command exited 1 after 498 seconds. Vitest reported 19,165 passed and one failed out of 19,166. The summary identifies apps/desktop/src/components/redis/RedisKeyBrowser.infiniteScroll.spec.ts, with 56 tests and one failure. The supplied tail does not include the failed assertion. Nearby metadata-cache output containing the word "failing" does not explain the Redis failure.
The configured environment had 3 CPUs, 8 GB RAM and image label lab-node:22. Actual runtime and operating-system versions are not established by that label. The scan recorded 31 CI workflow files, a tests directory and monorepo workspaces, and did not detect a Dockerfile. That scan does not establish whether the project's published Docker image works.
These checks did not exercise a packaged desktop installation, a real database connection, an AI provider, an MCP session or credential recovery.
MCP requires a separate installation
Installing DBX does not automatically install its MCP server. The README documents an npm launcher and precompiled native binaries. It places the connection allowlist and Read only, Data read/write and Full access modes in DBX Settings → MCP.
Those settings describe intended controls. Our run did not test their enforcement. For an initial evaluation, use database-level read-only credentials alongside the documented MCP read-only mode. Configure one disposable connection, inspect which connections the agent can list, and compare a query result with a known answer. An allowlist controls connection scope; it does not establish whether a query expresses your intent.
Web deployments have an additional connection path: the MCP server must point to the web backend. If the web login requires a password, the README says to provide the same password through DBX_WEB_PASSWORD. Windows portable builds require DBX_DATA_DIR to point to the directory containing dbx.db. These instructions were not executed in our sandbox.
The default Docker key travels with the data volume
The README says web and Docker deployments encrypt stored credentials using a managed data-directory key by default. The key must be backed up with dbx.db. Persisting the data volume therefore preserves both parts needed for ordinary recovery.
The same arrangement limits what encryption protects: copying or exposing the whole volume also exposes the key. A backup that includes the key needs access controls appropriate for the credentials it can unlock.
For production deployments, the README documents an external secret through DBX_SECRET_KEY_FILE, or DBX_SECRET_KEY supplied through a secret manager. It warns that explicit keys must never be rotated while encrypted data is in use. Before storing real credentials, decide who can read the volume, where the key will live and how both will be restored. We did not test migration or recovery.
Contributors face a separate data-handling concern. The README warns that development builds can share connections and history with an installed DBX instance. Check that shared state before treating a development launch as disposable, and avoid changing the same connection or global setting in both windows.
The release is newer than the measured checkout
Release v0.6.61, published on October 29, 2026, is described as an urgent fix to v0.6.60. Its notes say it reverts a plugin-workbench change affecting inactive-tab layout retention and restores earlier tab mounting and switching behavior.
That release establishes a specific maintenance change. It does not establish whether the October 3 Redis test failure persists or has been fixed. The current README guidance and the older sandbox results are separate evidence, and this review does not present them as a test of v0.6.61.
Choose by the workflow you need
DBeaver is relevant when JDBC connectivity shapes the choice. Its README lists schema, SQL and data editors and distinguishes Community from commercial driver coverage. Verify the edition against your required engine.
pgAdmin 4 is a PostgreSQL management application deployable on a web server or workstation. It is a useful candidate when PostgreSQL is your whole scope. Neither alternative was benchmarked against DBX here.
The documentation rating uses a five-point editorial rubric: 1 means essential operating guidance is missing; 2 means setup is described but important operating questions remain; 3 means setup and routine use are covered; 4 means explicit operational caveats and recovery instructions are also supplied; 5 requires independent reproduction of those instructions. DBX earns 4 for its documented MCP installation, credential-key lifecycle and development-data warnings. Setup ease, community and maturity remain unassessed because the evidence does not support numerical judgments.
Start with one disposable database and read-only credentials. Verify a known query result, inspect the agent's connection visibility, and rehearse recovering the connection data with its key before moving to real credentials.