# Database Support

> Understand DBX connection profiles, driver runtimes, specialized workspaces, and capability-gated advanced features.

Source: https://dbxio.com/en/docs/databases

Language: en

Relative links resolve against https://dbxio.com/en/docs/databases.



The new-connection picker provides 100+ database and service profiles. A profile defines defaults, form fields, presentation, and a driver entry point, but being able to connect does not mean every advanced feature is available.

The installed connection picker and 

`crates/dbx-core/assets/database-drivers.manifest.json`

 are authoritative for current types and capabilities. This page intentionally avoids a brittle exhaustive matrix.

## Connection Families

### SQL and Compatible Protocols

* Core SQL engines such as MySQL, PostgreSQL, SQLite, SQL Server, ClickHouse, Oracle, and Redshift
* MySQL-protocol or syntax profiles such as MariaDB, TiDB, OceanBase, Doris, SelectDB, StarRocks, Manticore Search, GoldenDB, and Dolt
* PostgreSQL-compatible profiles such as openGauss, GaussDB, KingbaseES, HighGo, Vastbase, and CockroachDB
* Vendor databases including DM, KWDB, YashanDB, GBase, Teradata, Vertica, Exasol, Firebird, and SAP HANA
* Agent/JDBC analytics engines such as Snowflake, Trino, PrestoSQL, Hive, Spark, DB2, Informix, Databricks, and BigQuery
* Cloud-managed relational services such as Google Cloud Spanner (Agent/JDBC, GoogleSQL and PostgreSQL dialects)

Protocol compatibility covers only connection and selected dialect behavior. Versions, system catalogs, DDL, privileges, and management APIs differ, so DBX uses separate profiles and capability overrides instead of enabling features by family name alone.

### File, Edge, and Hosted Databases

* SQLite, DuckDB, and Microsoft Access
* Cloudflare D1, Turso, and RQLite
* H2 and local databases reached through JDBC URLs

Desktop file paths belong to the local computer. Docker/Web paths belong to the server container or mounted host storage; a path on the browser computer is not mapped automatically.

### Specialized Data Models and Services

* Redis and MongoDB
* Elasticsearch, Easysearch, Meilisearch, and Manticore Search
* Qdrant, Milvus, Weaviate, and ChromaDB
* HBase
* Pulsar, Kafka, RocketMQ, and RabbitMQ
* etcd, ZooKeeper, Nacos, and Consul KV
* InfluxDB, IoTDB, TDengine, and other time-series or IoT profiles

These connections use key-value, document, search, vector, messaging, or configuration-center workspaces. They do not inherit every relational grid or SQL concept. See [Specialized Workspaces](/en/docs/specialized-workspaces).

## Driver Runtimes

| Runtime                | Description                               | Typical boundary                                                                                                   |
| ---------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Built-in native        | Rust driver compiled into DBX             | Available immediately after installation                                                                           |
| Native Agent / sidecar | DBX-managed Go, Rust, or external process | Requires platform files; DuckDB, Oracle, KingbaseES, XuguDB, RabbitMQ, and similar paths may use separate runtimes |
| JDBC Agent             | Java Agent plus a vendor JDBC driver      | Requires a JRE, Agent, and legally obtained vendor JAR                                                             |
| JDBC plugin            | Optional generic JDBC extension           | Unknown engines run with generic JDBC capabilities                                                                 |

See [Driver Management](/en/docs/driver-management) for installation, upgrades, offline packages, and runtime monitoring, and [JDBC Plugin](/en/docs/plugins) for custom JDBC.

### Oracle OCI (thick driver)

Oracle connections default to the thin driver. The connection dialog's driver mode also offers **OCI**, which runs the separate `oracle-oci` Agent built against the Oracle Call Interface so the Oracle Client handles the connection. The OCI driver is currently shipped for Windows x64.

* **Instant Client directory** is a global setting: enter the directory that contains `oci.dll` once, and every OCI connection reuses it. The directory is prepended to the Agent process's loader path.
* **NLS\_LANG** is process-scoped for the Oracle Client, so it is configured in two layers: a global default, plus an optional per-connection override. A connection that overrides NLS\_LANG gets its own Agent process instead of sharing one, so character sets never leak between connections.
* **TNS names, wallets, and sqlnet.ora**: `TNS_ADMIN` supports a global default plus a per-connection override (fill the directory in the OCI connection form, or leave it empty to follow the global default), so any OCI connection can use tnsnames.ora aliases, ADB wallets, and sqlnet.ora network options (compression, encryption) without switching to the TNS connection form; the TNS connection form also passes its directory to the Agent process.
* OCI only affects how the client library is loaded. Grid editing, DDL, transfer, and other features behave the same as on the thin driver.

## Capability Levels

The driver manifest uses capability levels from basic connection through controlled operations, with per-engine overrides:

| Level      | Meaning                                                        |
| ---------- | -------------------------------------------------------------- |
| Connect    | Establish a connection and run profile-supported basic queries |
| Browse     | Browse databases, schemas, tables, or specialized objects      |
| Understand | Add read-only source, search, and relationship workflows       |
| Operate    | Add controlled writes such as table data editing               |

Individual capabilities then control features such as:

* Schema search and ER diagrams
* Table data and table structure editing
* Table import and data transfer
* SQL file execution
* Field lineage and query explain
* Database creation, user administration, and driver management

Menu availability is therefore more meaningful than a static database name list. When an action is missing, check the DBX version, database profile, runtime mode, and installed components.

## Feature Boundaries

### SQL Files and Relational Tools

Redis, MongoDB, search, vector, HBase, configuration-center, and message-queue workspaces do not use relational SQL file execution. Some SQL engines support query and browse workflows without structure editing, import, or transfer.

### Import and Transfer

[Table Import](/en/docs/table-import) and [Data Transfer](/en/docs/data-transfer) filter connections by capability. Cross-engine paths also depend on type mapping, keys, identity columns, schemas, and target DDL support.

### Backup and Export

* [Database Export](/en/docs/database-export) is a capability-driven logical SQL export
* [Database Backup](/en/docs/database-backup) currently schedules consistent MySQL and PostgreSQL backups in Desktop only
* Cloud Sync and configuration export migrate DBX settings, not business database contents

### Desktop and Docker/Web

Both runtimes share most Rust core query, metadata, and safety policy, but are not feature-identical. Local SQL folders, system file selection, Deep Links, local CLI Agents, and scheduled database backup are Desktop-only. Web files, drivers, and Agents live in the server data directory.

## Default Ports and Connection URLs

Profiles prefill common defaults such as MySQL `3306`, PostgreSQL `5432`, Redis `6379`, MongoDB `27017`, SQL Server `1433`, Oracle `1521`, Elasticsearch `9200`, Meilisearch `7700`, and RabbitMQ AMQP `5672`. These are defaults, not requirements.

Services such as RabbitMQ may expose separate business and management ports. A custom AMQP port must not be used to infer the Management API port. SSH tunnels, HTTP proxies, TLS SNI, and physical dial targets should also be verified independently.

DBX parses many common DSNs and URLs, but parameters vary by version and cloud vendor. After a successful connection test, still verify the actual database, schema, SSL, and privilege scope.

## Local Test Environments

The repository includes pinned Docker Compose labs for ClickHouse, MariaDB, MongoDB, MySQL, PostgreSQL, and Redis. Use [Database Test Lab](/en/docs/database-lab) for connection, driver, and regression testing.

## Related Pages

### [Specialized Workspaces](/en/docs/specialized-workspaces)

Review non-relational, search, vector, messaging, and configuration-center interfaces.

### [Driver Management](/en/docs/driver-management)

Install and diagnose native Agents, sidecars, JDBC Agents, and JREs.

### [Production Safety](/en/docs/production-safety)

Understand database privileges, read-only protection, production protection, and automation boundaries.

