Database Support

Connection Profiles

The connection dialog exposes ready-to-use profiles with default ports and driver labels.

Default Ports

Feature Matrix

DBX intentionally enables advanced workflows only where the app has enough metadata and SQL-generation support.

Connection Options

Most network databases support host, port, username, password, default database, optional URL parameters, SSL, connection color, and tunnel / proxy settings. File-based engines replace host and port with a file picker.

DBX can also parse common connection URLs for engines such as MySQL, PostgreSQL, Redis, MongoDB, ClickHouse, SQL Server, Oracle, Elasticsearch, DM, GaussDB, KWDB, openGauss, TDengine, XuguDB, Access, Teradata, Vertica, Firebird, Exasol, GBase, YashanDB, SAP HANA, InfluxDB, QuestDB, IoTDB, etcd, Nacos, RQLite, and Databricks.

Cloudflare D1

Create a Cloudflare D1 connection with the Account ID, D1 Database ID (UUID), and an API Token. The token needs D1 Read permission for browsing and queries; add D1 Write for inserts, updates, DDL, imports, or transfers. DBX uses Cloudflare's HTTPS API directly, so SSH and proxy transport layers are not available for this profile.

Nacos Console

Nacos connections open a dedicated admin console for namespaces, configs, services, instances, config history, and raw API requests. Use the Nacos console/admin API address when creating the connection. Nacos 3 Docker deployments usually expose that console on 8085; older deployments may share 8848 with the service port.

ClickHouse TLS

ClickHouse connections support TLS encryption. When creating a ClickHouse connection, enable the TLS toggle to connect over HTTPS instead of HTTP. This is recommended for production ClickHouse instances or any ClickHouse Cloud deployments.

GaussDB Native Driver

GaussDB and openGauss now use a native Rust driver (rust-gaussdb) instead of ODBC. Connections that previously used the PostgreSQL compatibility path are auto-migrated to the GaussDB driver. The native driver provides better type handling and metadata support specific to GaussDB.

DuckDB File and Memory Modes

DuckDB connections support two modes:

• File mode: Select a .db or .duckdb file for persistent storage
• Memory mode: Use an in-memory database for temporary analysis. Data is lost when the connection is closed.

Create a new DuckDB database file directly from the connection form by entering a path that does not yet exist.

DuckDB Connection Init Script

DuckDB connections can run a SQL script every time the connection is established. Configure it in the Init Script field of the connection dialog. Typical uses are loading extensions, creating secrets, tuning session options, and attaching additional catalogs:

INSTALL quack;
LOAD quack;
ATTACH 'quack:analytics-host' AS remote (TOKEN 'your_token');

Or attach a DuckLake catalog:

INSTALL ducklake;
LOAD ducklake;
ATTACH 'ducklake:/data/lake/meta.ducklake' AS lake (DATA_PATH '/data/lake/files');

• Databases attached by the script (local files, DuckLake, remote Quack servers, ...) appear in the sidebar like configured attached databases, and are re-attached automatically on every reconnect. Prefer an explicit AS alias so catalog names stay stable.
• Statements run in order; when one fails, the connection fails with the statement number and the engine error so the script is easy to fix.
• The script runs on every new connection, so prefer statements that are safe to repeat, and use guards such as IF NOT EXISTS where the engine or extension supports them.
• The init script is stored like a connection password: it lives in the local secret store, is never written to plain-text config files, and only syncs inside the encrypted sensitive payload — tokens such as the Quack TOKEN above stay out of public sync snapshots and exports.

In-Memory SQLite

SQLite connections can use :memory: as the file path for ephemeral, in-memory databases. This is useful for quick experiments or temporary data transformations.

Doris / StarRocks Multi-Catalog

Doris and StarRocks are MPP engines that federate external data through catalogs (SHOW CATALOGS). DBX lists every catalog the current user can read and renders them as a catalog → database → table tree:

• The built-in internal catalog shows the engine's own databases and tables.
• External catalogs (Hive, Iceberg, Hudi, Paimon, JDBC, etc.) list their databases and tables the same way. Catalogs you lack permission to read are skipped silently.
• When only the internal catalog is present, the sidebar stays flat (no catalog grouping layer) so single-catalog deployments are unaffected.

Opening a table from an external catalog previews its data using the 3-part catalog.database.table name, so no session SWITCH is needed. External catalogs expose tables and views only — routines, sequences, triggers, and foreign keys are not available.

Extending Support

Use the JDBC Plugin when a database is not covered by the built-in profiles or when your team must use a vendor JDBC driver. JDBC keeps vendor driver JARs outside the main DBX app, so you control which driver files are installed.