# Specialized Workspaces

> Manage Redis, MongoDB, Apache CouchDB, search and vector databases, HBase, message queues, etcd, ZooKeeper, Nacos, and Consul KV in DBX.

Source: https://dbxio.com/en/docs/specialized-workspaces

Language: en

Relative links resolve against https://dbxio.com/en/docs/specialized-workspaces.



In addition to the SQL editor and data grid, DBX opens specialized workspaces for specific connection types. These interfaces use each system's native object model and management APIs, including Redis keys, MongoDB documents, vector collections, message queue topics, etcd keys, ZooKeeper ZNodes, Nacos configurations, and Consul KV entries.

Specialized capabilities are enabled dynamically based on database type, server version, driver, and account privileges. If an entry point is missing, check 

[Database Support](/en/docs/databases)

, the connection test result, and server permissions.

## Workspace Overview

| Category                      | Connection types                                         | Main entry points                                                                               |
| ----------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Key/value and document        | Redis, MongoDB, CouchDB                                  | Key or document browsing, filtering, editing, commands, and aggregation workflows               |
| Search and document indexes   | Elasticsearch, Easysearch, Meilisearch, Manticore Search | Index/document browsing and engine-specific requests                                            |
| Vector databases              | Qdrant, Milvus, Weaviate, ChromaDB                       | Collection browsing, vector search, upsert, delete, and request preview                         |
| Wide-column and column family | HBase                                                    | Namespaces, table structure, column families, and row data                                      |
| Message queues                | Pulsar, Kafka, RocketMQ, RabbitMQ                        | Topics, subscriptions or consumers, messages, monitoring, permissions, policies, and admin APIs |
| Registry and configuration    | etcd, ZooKeeper, Nacos, Consul                           | Keys/ZNodes, cluster status, access control, configuration, services, and instances             |
| Runtime status                | MySQL, PostgreSQL, Redis, etcd, Nacos, and others        | Dashboards, processes or sessions, metrics, and database-specific administration views          |

## Redis and MongoDB

Redis and MongoDB have dedicated guides:

### [Redis Browser](/en/docs/redis)

Browse and search keys, edit multiple data types, run commands, and inspect statistics and Slowlog.

### [MongoDB Browser](/en/docs/mongodb)

Browse collections and documents, filter, paginate, edit, manage indexes, and work with GridFS data.

When a connection is read-only, DBX disables or rejects mutations in Redis, MongoDB, and GridFS. Dangerous Redis commands also pass through a separate command-safety classifier.

## DynamoDB PartiQL

DynamoDB connections support native PartiQL in the query editor:

```sql
SELECT "pk", "status" FROM "orders" WHERE "pk" = 'order-1001';
INSERT INTO "orders" VALUE {'pk': 'order-1002', 'status': 'NEW'};
UPDATE "orders" SET "status" = 'PAID' WHERE "pk" = 'order-1002';
DELETE FROM "orders" WHERE "pk" = 'order-1002';
```

DBX calls the AWS SDK's [ExecuteStatement](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExecuteStatement.html) rather than translating PartiQL into another SQL dialect. DynamoDB determines supported syntax, IAM permissions, and errors. This is not full relational SQL: JOIN, SQL-file execution, DDL, and cross-statement transactions are not enabled. Existing `DBX DYNAMODB SCAN` / Item commands remain supported.

SELECT follows service `NextToken` values, including intermediate pages with no filter matches. Results respect the editor's row cap and a 1,000-page safety bound. A reached limit or a service response without a usable continuation token marks the result truncated and emits a warning instead of presenting partial data as complete. Use the editor row cap or narrower conditions, not SQL `LIMIT`. SELECT without a partition-key condition may scan substantial data and incur charges.

Query results paginate the returned data locally, without injecting SQL `LIMIT` / `OFFSET` or derived-table `COUNT` queries. Document-browser cursor pagination is unchanged.

Projections preserve DynamoDB representations for large numbers, binary, and nested values without adding synthetic document-editing `_id` fields. Singleton writes never enter the client pagination loop; their affected count acknowledges one successful operation, not an exact changed-row count supplied by the service. Existing read-only, production-confirmation, timeout, and cancellation paths remain in effect.

## Search and Document Indexes

Elasticsearch, Easysearch, Meilisearch, and Manticore Search use index- and document-oriented browsing. DBX displays indexes or collections from driver metadata and provides entry points for browsing, querying, and inspecting documents.

Keep these boundaries in mind:

* Elasticsearch, Easysearch, and Meilisearch connect to HTTP/HTTPS endpoints rather than traditional database TCP ports
* Meilisearch uses DBX's built-in Rust HTTP driver; its API key is stored in the connection password field and the default port is `7700`
* TLS, proxying, and authentication depend on the connection type and server configuration
* Document queries and mutations vary by driver, server version, and account privileges
* SQL workflows such as schema diff or SQL file execution only appear when the engine reliably supports them

## Apache CouchDB

Apache CouchDB uses DBX's built-in Rust HTTP driver. Each CouchDB database appears as a document collection that opens in the document browser.

* Connect to the CouchDB HTTP/HTTPS endpoint, default port `5984`. Enable TLS for `https://`; `couchdb://host:5984` URLs can be pasted directly
* Credentials use HTTP Basic authentication from the connection username and password fields
* Without a filter, documents are paged through `_all_docs`. A filter is sent as a Mango `selector` to `_find`, and pagination follows CouchDB's `bookmark`
* Documents can be inserted, edited, and deleted; if an update omits `_rev`, DBX fetches the current revision first, and deletes always use the current revision
* The query editor accepts REST requests in the form `METHOD /path` followed by an optional JSON body, for example `GET /_all_dbs` or `POST /mydb/_find`

DBX classifies every request before it runs. `GET`, `HEAD`, `OPTIONS`, and read-only `POST` endpoints (`_find`, `_explain`, `_all_docs`, `_bulk_get`, and view queries under `_design/*/_view/*`) are reads. Other `POST`, `PUT`, and document-level `DELETE` requests are writes, while `PUT /{db}` and `DELETE /{db}` are treated as dangerous. These levels drive the same confirmation and read-only safeguards used for other engines.

## Vector Databases

Qdrant, Milvus, Weaviate, and ChromaDB open a vector collection workspace. Depending on the engine, it can:

* Browse collections and records
* Display dimensions or schema details
* Run Top K similarity search with an input vector
* Preview or edit the raw request
* Upsert vectors, payloads/metadata, or documents
* Delete records by ID or request condition

The products use different APIs, collection models, and search parameters. DBX generates an engine-specific request template, but dimensions, field names, distance metrics, and index settings must match the target database.

Vector upserts and deletes are write operations. Production connections should combine database privileges, DBX read-only/production protection, and human request review.

## HBase

The HBase workspace is organized around namespaces, tables, column families, and row keys. Depending on Agent and server capabilities, it can browse table structure and rows and expose create, alter, truncate, or delete operations on writable connections.

Scan ranges and filters directly affect server load. For large tables, constrain row-key ranges, page size, and returned columns instead of treating a full scan like a normal relational data grid.

## Message Queues

Pulsar, Kafka, RocketMQ, and RabbitMQ share the message queue console framework, but each system only shows panels supported by its own capabilities. Common areas include:

* Topics plus namespaces, tenants, or virtual hosts
* Subscriptions, consumer groups, producers, and clients
* Message queries, sending, and traces
* Broker or cluster monitoring
* Permissions, policies, quotas, and related administration
* Raw API requests exposed by the driver

Pulsar emphasizes tenants, namespaces, and subscriptions; Kafka uses topics, consumer groups, and brokers; RocketMQ adds message and trace workflows; RabbitMQ uses virtual hosts, exchanges/queues, connections, policies, and permissions.

Message queue panels are capability-driven. Server versions, management APIs, account privileges, or a missing management port can make individual tabs unavailable.

## etcd, ZooKeeper, Nacos, and Consul

### etcd

etcd provides a key browser, cluster dashboard, and access-control workspace. Available features include prefix browsing, value editing, lease information, member and health status, metrics, and user/role management.

### ZooKeeper

ZooKeeper displays hierarchical data as a ZNode tree. You can browse paths and inspect node content, then create, update, or delete nodes when permissions and connection state allow it.

### Nacos

The Nacos workspace covers configuration and services and can also manage namespaces. Depending on the connection and console API, it includes:

* Configuration creation, editing, deletion, and full-text search
* Configuration history, version diff, and rollback
* Batch import/export and cross-namespace copy
* Services, instances, weights, and health data
* Dashboard and Raw API access

Configuration history can require an additional console URL and credentials. If the connection works but history is unavailable, check the console settings in the connection form.

### Consul

The Consul workspace is split into independently loaded Overview, KV, Services, Health, Sessions, ACL, Scope, Service Mesh, Tools, and Operator domains. Capability probes distinguish supported, unsupported, forbidden, and unknown endpoints, so a permission failure in one domain does not clear data loaded by another.

Connections accept an HTTP or HTTPS API address, ACL Token, Datacenter, Namespace, Admin Partition, read consistency, CA certificate, mTLS identity, certificate-verification override, timeout, and DBX Transport Layer. Agent Service and Check writes additionally require a verified, explicit Agent target; DBX refuses those writes when a load balancer makes the target ambiguous.

KV supports recursive search, versioned prefix export, immutable import preview, CAS conflict handling, transactions, atomic rename/copy, bounded transactional prefix deletion, and cancellable blocking-query Watch. Consul transactions are limited to 64 operations; larger imports and deletes are deterministically split and explicitly reported as non-atomic across batches. Cross-connection or cross-Datacenter migration is a DBX client read/write workflow, not native Consul replication.

Catalog and Health remain read-only discovery views. Agent Service/Check, Session/Lock, ACL Token/Policy/Role, Enterprise Namespace/Partition, and Service Mesh resources use domain-specific DTOs and confirmations. ACL secrets and peering tokens are treated as one-time sensitive values and are not stored in the Consul frontend cache or normal export formats.

Prepared Query, Event, and Coordinate are available under Tools. Operator reads and snapshot download are experimental. Snapshot restore, Autopilot updates, Raft changes, Keyring changes, and License updates are disabled by default with separate feature switches; enabling one does not enable another.

Consul has no per-Key history API and no native cross-Datacenter KV replication API. 

`ModifyIndex`

, blocking indexes, and snapshots are not presented as Key history. Enterprise and Operator availability depends on Consul edition, version, Agent role, ACL policy, and explicitly enabled DBX safety settings.

## Dashboards and Administration Views

Some connections expose runtime status pages from the object tree or a tab, including:

* MySQL and PostgreSQL dashboards or process/session views
* Redis instance information, statistics, and Slowlog
* etcd members, database size, and Raft/lease-related metrics
* Nacos namespace, configuration, service, and instance statistics
* Message queue broker, topic, client, and consumption state

These pages are for inspection and troubleshooting, not long-term monitoring. Use Prometheus, Grafana, or a vendor monitoring platform when you need alerts, historical trends, and capacity planning.

## Safety and Compatibility Boundaries

* Specialized workspaces respect connection read-only state; MCP-exposed specialized commands also follow the global MCP policy.
* Production protection still applies to writes recognized by DBX, while database privileges remain the final boundary.
* Drivers expose only capabilities they can implement reliably, so tabs can differ even within one category.
* Management APIs and data protocols can use different ports, such as RabbitMQ Management API or the Nacos console API.
* File paths and network reachability in Docker/Web belong to the server environment, not the browser computer.

### [Review the database matrix](/en/docs/databases)

Check connection types, default ports, driver architecture, and advanced feature coverage.

### [Configure drivers](/en/docs/driver-management)

Install or update Agent/JDBC drivers and handle runtime dependencies.

### [Set write protection](/en/docs/production-safety)

Configure read-only connections, production protection, and MCP permissions.

### [Troubleshoot connectivity](/en/docs/ssh-tunnel)

Configure TLS, SSH, SOCKS5, HTTP proxies, or HTTP tunnels.

