Elasticsearch

AddisDB talks to Elasticsearch over its REST API and gives the editor three ways in: type a bare index name for a quick look, paste a raw query body, or write an explicit method and path for anything else.

Who it is for

Elasticsearch is an inverted-index search engine that also does analytics well. It ranks results by relevance, handles typos, synonyms and language stemming, and aggregates across hundreds of millions of documents fast enough for an interactive dashboard.

Almost every surprise it produces traces back to the mapping. A field mapped as text is analyzed into tokens and is searchable but not exactly matchable; the same field mapped as keyword is exact, sortable and aggregatable. That is why a term query on a text field returns nothing while a match query on it works.

Use it for product and site search, log and observability data, and any dashboard that needs to slice a large document set on the fly. It is a search layer over your data, not a system of record.

Set up the cluster

1. Elastic Cloud: create a deployment and copy the Elasticsearch endpoint. The elastic user’s password is shown once at creation — save it.
2. Self-hosted 8.x enables security by default: on first start it prints the elastic password and an enrollment token. Capture that output.
3. Local: docker run -p 9200:9200 -e discovery.type=single-node -e xpack.security.enabled=false docker.elastic.co/elasticsearch/elasticsearch:8.14.0 for a no-auth sandbox.
4. Confirm the cluster answers: curl http://localhost:9200.
5. For anything but a sandbox, create an API key or a role-scoped user rather than reusing elastic.

Connect from AddisDB

1. New Connection → Elasticsearch under Search. Port prefills to 9200 and the username to elastic.
2. Enter the host and password. Index is optional — set it to scope queries to a default index, or leave it blank to see everything.
3. Elastic Cloud endpoints are HTTPS on port 443: set the port accordingly and SSL mode to require.
4. Test, then Save.

How to query it

// Just an index name — a capped match_all
products

// A raw query body against the default index
{ "query": { "match": { "title": "wireless headphones" } }, "size": 25 }

// Or an explicit request
GET /_cat/indices?format=json

The explicit form is the one that unlocks the rest of the API. GET /products/_mapping tells you why a field is not behaving; GET /_cat/indices?v shows size and document count per index; and _search with an aggs block returns an aggregation the Chart view can draw.

// Top categories — an aggregation, not a search
{ "size": 0, "aggs": {
    "by_category": { "terms": { "field": "category.keyword", "size": 10 } }
} }

Note the .keyword suffix: aggregating on the analyzed text field fails, while its keyword sub-field is exactly what you want. That one detail accounts for a surprising share of the errors people hit here.

What AddisDB gives you

• Indices listed in the sidebar with their mapped fields.
• Hits flattened into the grid from _source, enriched with _id, _index and _score so relevance is visible as a column.
• The JSON tab for the untouched response — aggregations included.
• Read-only enforcement — PUT and DELETE are blocked, and only read endpoints such as _search, _count and _mget are allowed through POST.
• The Chart view for aggregation results, and AI chat grounded in your indices.
• The Live Monitor over _cat/indices and _tasks, with per-index store bytes and doc counts.