Couchbase

Couchbase stores documents but queries them with N1QL — SQL++ — so the editor feels like SQL even though the data is JSON. AddisDB talks to the Query Service over its REST API and lists your buckets, scopes and collections as tables.

Who it is for

Couchbase pairs a memory-first key-value layer with a real query engine, so the same data serves sub-millisecond lookups and ad-hoc SQL. It replicates across data centres and runs the same way at the edge, on-premises, or in its managed Capella service.

Its services are separable — Data, Query, Index, Search, Analytics — and each can be given its own nodes. That is why "the cluster is up" and "the Query Service is reachable" are two different statements, and why a connection can fail while the admin console looks perfectly healthy.

It suits session and profile stores that also need reporting, product catalogs with heavy read traffic, and teams who want document flexibility without giving up SQL.

Set up the cluster

1. On Couchbase Capella, create a cluster and a bucket, then add your IP under Allowed IP Addresses.
2. Create database credentials (a username and password) with read access to the bucket.
3. Confirm the Query Service is running on your cluster — it is what AddisDB talks to.
4. Self-hosted: docker run -p 8091-8096:8091-8096 couchbase, then complete the setup wizard at localhost:8091 and create a bucket.
5. Note the hostname of a node running the Query Service. The default port is 8093, or 18093 over TLS.

# A local cluster; finish setup at http://localhost:8091
docker run -d --name couchbase -p 8091-8096:8091-8096 couchbase:community

Connect from AddisDB

1. New Connection → Couchbase under Document. Port prefills to 8093 and the username to Administrator.
2. Enter the Query Service host and your cluster credentials. Bucket is optional — leave it blank to browse everything.
3. If your cluster sits behind a load balancer or uses a non-standard path, paste the full Query Service base URL into the Connection URL box instead.
4. Test, then Save.

Port 8091 is the management console, not the query endpoint. Pointing a connection at it is the most common first mistake — the host answers, and every query fails.

How to query it

-- N1QL reads like SQL over JSON
SELECT name, address.city
FROM `travel-sample`.inventory.hotel
WHERE country = "United States"
LIMIT 25;

Two pieces of syntax carry most of the difference from ordinary SQL. UNNEST flattens an array inside a document into rows, the way a join would across tables. And a keyspace is three parts — bucket, scope, collection — with the bucket backticked when its name contains a hyphen.

-- One row per review, from an array nested in each hotel
SELECT h.name, r.author, r.ratings.Overall
FROM `travel-sample`.inventory.hotel h
UNNEST h.reviews AS r
WHERE r.ratings.Overall >= 4
LIMIT 25;

A query that returns "no index available" is not a syntax error: N1QL requires an index to serve a predicate, and a fresh bucket has none. CREATE PRIMARY INDEX is fine for exploring and a bad idea in production.

What AddisDB gives you

• Buckets, scopes and collections listed as tables in the sidebar, read from system:keyspaces.
• Results flattened into the grid, with the JSON tab for the raw documents.
• Double-locked read-only: AddisDB rejects non-SELECT statements before they leave your machine, and also sets the query’s readonly flag so the server refuses writes independently.
• The Chart view for aggregations, and ⌘K search across every connected database.
• AI chat grounded in your real keyspaces.
• Query tabs and history for the N1QL you will want again.