CodeMirror 6 with SQL syntax highlighting, metadata-aware autocomplete, Cmd+Enter execution, selected SQL execution, SQL formatting, diagnostics, and 9 editor themes. Persistent query history, saved SQL snippets, tab restore, and SQL file execution keep repeat work close at hand.
AI SQL Assistant
Describe what you want in plain language — get SQL back. DBX can explain queries, optimize SQL, fix errors, and run AI-generated SQL through built-in safety checks. Works with Claude, OpenAI, local models, or any OpenAI-compatible endpoint.
Data Grid
Virtual-scrolled table that handles large result sets. Inline editing, SQL preview before save, WHERE / ORDER BY controls, DataGrip-style filters, LIKE / NOT LIKE context filters, sorting, full-text search, pagination, column resize, auto-fit, row numbers, zebra stripes, and full cell details. Export or copy as CSV, JSON, Markdown, XLSX, or INSERT statements.
MQTT — topic tree navigation, subscribe, and publish
Nacos / Consul / ZooKeeper / etcd — service discovery, KV / config browsing, health, and ACL
Plugin System
Extensible by design — new connection types and tools arrive as plugins: S3 browsing, Kubernetes, LDAP, and more from the built-in store
Signed & sandboxed — every plugin package is signature-verified before install; plugin UI runs sandboxed with its own sidecar process
Build your own — Go / TypeScript SDKs with npx @dbx-app/plugin-cli scaffolding; publish to the Marketplace via t8y2/dbx-store
Safety & Connectivity
SSH tunnel (key & password) · database and AI proxy settings · auto-reconnect on connection loss · confirmation dialogs for destructive operations · encrypted config export/import · color-coded connections · driver store and optional JDBC plugin
Polished UI
Dark mode with native title bar sync · 9 editor themes · English, 简体中文 & Español · layout preferences · built-in auto-update
AI Agent Integration (MCP)
DBX provides a separate Rust-powered MCP server that lets AI coding agents query databases using connections configured in DBX. The MCP server is distributed independently from the desktop application, so installing DBX does not automatically install the MCP executable.
Manage the connection allowlist and the Read only, Data read/write, and Full access modes in DBX Settings → MCP. The machine-readable values remain read_only, safe_write, and high_risk_write; client configs do not need permission or connection-scope environment variables.
For upgrade compatibility, an existing DBX_MCP_ALLOW_WRITES=0 (or false) remains a read-only restriction only until a central MCP policy is saved for the first time; it can never enable writes or override a saved policy.
Windows portable builds need DBX_DATA_DIR in the MCP config, pointing to the data directory next to DBX.exe (the folder that contains dbx.db).
For DBX Web or Docker deployments, point the MCP server at the Web backend API. If the Web login page requires a password, set DBX_WEB_PASSWORD to the same password used there:
Works with Claude Code, Cursor, Windsurf, and any MCP-compatible agent. Supports listing connections, browsing tables, executing SQL, and opening tables directly in DBX's UI.
Precompiled native binaries are also published for macOS, Linux, and Windows in package releases. They run without Node.js and are suitable for offline or server environments. The npm installation uses the same Rust binary through a small Node.js launcher.
DBX also provides a dedicated CLI package for terminal, script, and Codex workflows:
npm install -g @dbx-app/cli
# or via Homebrew
brew tap t8y2/tap && brew install dbx-cli
dbx agent setup
dbx connections list --json
dbx query local "select 1" --json
The CLI includes the official DBX Agent Skill. dbx agent setup installs or updates it offline under ~/.agents/skills/dbx, so shell-capable AI agents know how to use DBX CLI safely.
Updates then arrive through the regular flatpak update. See the DBX page on FlatPark for details.
Self-Hosted (Docker)
For scheduled backups after closing the desktop app or browser, see
Background Database Backups, including
Windows/macOS/Linux startup and persistent container backup volumes.
DBX provides a web version that can be deployed via Docker. The examples use
the latest tag to pull the current release.
# The default keeps the key in the persistent /app/data volume.
docker run -d --pull=always --name dbx -p 4224:4224 \
-v dbx-data:/app/data \
t8y2/dbx:latest
This uses the cross-platform dbx-data named volume. Users in China can use
the CNB image, docker.cnb.cool/dbxio.com/dbx:latest, for faster pulls.
For Docker Compose, deploy/docker-compose.yml remains the source-build
configuration. To deploy a published image, use
deploy/docker-compose.release.yml:
docker compose -f deploy/docker-compose.release.yml up -d
services:
dbx:
image: t8y2/dbx:latest
# For faster pulls in China, use the CNB image instead:
# image: docker.cnb.cool/dbxio.com/dbx:latest
pull_policy: always
ports:
- "4224:4224"
volumes:
- dbx-data:/app/data
restart: unless-stopped
volumes:
dbx-data:
Open http://localhost:4224 in your browser. Multi-arch images (amd64 / arm64) are available.
Connection, plugin, AI, and tunnel credentials are encrypted before they are
written to dbx.db. Desktop builds use the local platform credential store
(macOS Keychain, Windows Credential Manager, or Linux Secret Service).
Web/Docker and directly running dbx-web use the same managed data-directory
key by default: ${DBX_DATA_DIR}/.dbx/secret.key. The key is created only when
migration starts or the first sensitive value is written, and must be backed up
together with dbx.db. Persisting /app/data is therefore sufficient for a
normal Docker deployment. This key protects the database contents, but cannot
protect the whole data volume if the volume itself is copied or exposed.
Windows portable builds are the exception to the desktop platform-key rule.
To remain portable across computers, they keep the local storage key at
data/.dbx/secret.key; move and back up the complete data directory. If an
older portable profile already contains ciphertext protected by Windows
Credential Manager, launch the new build once on the original computer so DBX
can verify and copy that key to the USB drive. If the original computer or key
is gone, the ciphertext cannot be recovered automatically; restore the original
key or a pre-migration backup. Keeping the key beside the database means anyone
who obtains or copies the whole drive can also decrypt its credentials.
For production deployments, replace the managed key with a Docker/Kubernetes
Secret by setting DBX_SECRET_KEY_FILE, or provide DBX_SECRET_KEY through a
secret manager. Explicit keys take precedence and must never be rotated while
encrypted data is in use. Without a usable key, business APIs remain blocked
and the browser displays the data security upgrade screen.
When running the binary directly, set DBX_DATA_DIR=/var/lib/dbx to use
/var/lib/dbx/.dbx/secret.key with the same lifecycle and backup rules.
When upgrading from a release that stored credentials in plain text, Desktop
and Web display a Data Security Upgrade wizard before opening the main
application. Choose Start upgrade to create a restricted backup, migrate
legacy database/JSON credentials, and verify that encrypted values can be
read. Failures retain the original data and backup; fix the issue shown in
the wizard and choose Retry. The backup path is shown after success.
Once you have verified your connections, Delete migration backups asks
for confirmation and removes the migration backup directory and the legacy
JSON .bak files created by that migration. Unrelated backup files are kept.
Users with no legacy data proceed directly after the initial check.
Local CLI and standalone MCP can reuse the existing platform credential
store on the same device, or read an explicitly configured
DBX_SECRET_KEY_FILE/DBX_SECRET_KEY. They do not create keys during the
startup check or automatically migrate legacy data. A
DATA_MIGRATION_REQUIRED error means that you must first open the same data
directory in Desktop or Web and complete its upgrade wizard. For headless
hosts without a platform credential store, configure the persistent key.
Cross-device exports use a separate sync passphrase and never contain the
local storage key. For installed builds, or when copying only dbx.db, platform
keys do not move with the database; use encrypted export/import instead. A
Windows portable build must move the complete data directory containing both
dbx.db and .dbx/secret.key.
make installs root dependencies when needed and starts the local Tauri desktop development environment.
Development builds can run alongside an installed DBX instance and share its local data, including connections and history. Avoid changing the same connection or global setting in both windows at once.
[!TIP]
DuckDB compilation takes a while. If you're not working on DuckDB features,
skip it to speed up local builds:
# Fast checks (skip DuckDB)
make cargo-check-fast
make cargo-test-fast
# Tauri dev without DuckDB
make dev-fast
The --no-default-features flag only affects local development.
Release builds (pnpm tauri build) always include DuckDB.
Web version:
make dev-web # frontend
make dev-backend # backend
Documentation site:
make docs
The official DBX documentation site lives in docs/. If you want to improve the website content or documentation pages, edit the files under docs/ and run make docs to preview the site locally.
Plugin authors should start with Develop and Submit DBX Plugins. Plugin source normally stays in its own repository; Marketplace listing pull requests go to t8y2/dbx-store, while plugin host, SDK, and CLI changes go to this repository.
For clean, reproducible local database instances, use the versioned Docker Compose recipes under deploy/database/:
DBX is free and open source, but ongoing maintenance, database compatibility testing, infrastructure, and release work require sustained time and resources.
Support DBX — voluntary donations via WeChat or Alipay
Sponsors & Partners — sponsorship, infrastructure, tools, and community collaboration
