FlatQL vs Elasticsearch Head: a 2010 cluster front end and a 2026 SQL workbench

elasticsearch-head is "A web front end for an Elasticsearch cluster" (README), written by Ben Birch and released under the Apache License 2.0 with a copyright line of 2010-2013 (LICENCE). For years it was the first thing people installed next to a new cluster: a single page showing the node and shard topology, a document browser, a point-and-click query builder and a text box for any REST call. It still works as a Chrome extension. FlatQL is a web and desktop SQL workbench built for Elasticsearch 6 to 9 and OpenSearch 1 to 2. It runs SQL with joins across indices, shows the Query DSL behind every statement, and exports results as files. The two tools are sixteen years apart in design, and that is the useful way to compare them.

Sixteen years apart, in one table#

Where Elasticsearch Head is the better fit#

There are three honest cases for elasticsearch-head in 2026.

The first is an old cluster. The README documents Docker images tagged 5, 2 and 1, and plugin installs for 0.x, 1.x and 2.x (README). If you are keeping a 2.x or 5.x cluster alive and need to see its shards, head was built for exactly that version and its topology view has aged well. FlatQL starts at Elasticsearch 6.

The second is the Chrome extension itself. It installs from the Chrome Web Store, and the README notes "you don't need to enable CORS with this method". For a developer with a local node on port 9200 who wants to glance at index sizes and shard state, it is a one-click, zero-configuration window, released under Apache 2.0 with no account and no server.

The third is cluster-level operations. The project page describes the overview as a place to "perform index and node level operations" (project page). FlatQL does not open, close, delete or move anything; it reads.

What head does not have is any recent development: the last commit is from November 2020 and the last release, v5.0.0, is from April 2018 and is described as a "Release for compatibility with elasticsearch 5.x" (releases). That is a statement of fact about the repository, not a judgment; the software does what it did.

Where FlatQL is the better fit#

FlatQL is the better fit for any cluster running Elasticsearch 6 or later, and for any question that spans more than one index.

The structured query builder in head composes a single Query DSL request against one index. FlatQL takes SQL and decides what to push to the cluster and what to compute itself:

SELECT l.service, l.region,
       COUNT(*) AS requests,
       SUM(IFF(l.status_code >= 500, 1, 0)) AS server_errors,
       LAG(COUNT(*)) OVER (PARTITION BY l.service ORDER BY l.region) AS previous_region
FROM "logs-*" AS l
WHERE l."@timestamp" >= '2026-11-01' AND l.level IN ('WARN', 'ERROR')
GROUP BY l.service, l.region
ORDER BY server_errors DESC
LIMIT 50;

The time and level filters go to the cluster as a bool filter; the GROUP BY is pushed as a composite aggregation because every key is a plain field and every aggregate is a plain COUNT or SUM; the IFF and the LAG window run in the engine. Show as DSL displays the composite aggregation request that was sent, which is also the quickest way to learn Query DSL from SQL you already know (Show as DSL). Add a JOIN to suppliers and the engine fetches both sides, up to about 50,000 rows per index per statement, and joins them.

Connecting is also simpler on a secured cluster. head's standalone server requires http.cors.enabled: true in elasticsearch.yml, and it passes basic auth through auth_user and auth_password URL parameters (README). FlatQL takes an API key, a username and password, or an Elastic Cloud ID, and changes nothing on the cluster; see connect a cluster. In a team, the credential is encrypted server-side and members never see it, while an owner grants read or write per index pattern and FlatQL enforces it on every request.

Then there is everything a 2010 front end was never asked for: streaming exports to CSV, TSV, JSON, NDJSON, Excel or Parquet up to 5,000,000 rows; charts and pivots on the result; a history of every statement with user, connection and duration; and Ask FlatQL, which reads your mappings and drafts the SQL or DSL for you without running it.

Using both#

If you still have a 5.x cluster, keep head's Chrome extension pinned for it and use FlatQL for the 7.x, 8.x and 9.x clusters it cannot see. On a modern cluster, head's "Any Request" panel is roughly what Kibana's Console or Elasticvue's REST view give you today, and either of those is the natural upgrade for the admin half of head's job; FlatQL replaces the query half. The Elasticvue comparison and the Cerebro comparison cover the two most common admin-side successors, and the elasticsearch-head alternatives roundup lists the rest.

The Free plan covers one cluster and the full SQL engine, which is enough to run the query above against your own logs-* indices. Details on the pricing page.