FlatQL vs Grafana for Elasticsearch

Grafana is a visualisation and alerting platform, and its Elasticsearch data source ships preinstalled so you can "query and visualize logs or metrics stored in Elasticsearch" and annotate graphs with log events (Grafana docs). You build panels from aggregations, arrange them on dashboards and attach alert rules. FlatQL is a SQL workbench: you type a statement, the cluster runs the filters and GROUP BY, an embedded engine runs joins and window functions, and you get a grid, a chart or an export. Grafana answers "what does this look like over time, all the time". FlatQL answers "what is the number right now, and give me the rows".

How each one talks to the cluster#

Grafana's Elasticsearch data source supports Elasticsearch 7.17 or later, 8.x, 9.x and Elastic Cloud Serverless (Grafana docs). Its query editor offers Metrics, Logs, Raw DSL in Code mode and ES|QL (query editor). Filters use Lucene query syntax, with the note that boolean operators must be uppercase. The Metrics type builds aggregations from a fixed menu: bucket aggregations (terms, filter, geo hash grid, date histogram, histogram and experimental nested) and metric aggregations (count, average, sum, max, min, extended stats, percentiles, unique count, top metrics, rate), plus pipeline and sibling-bucket aggregations. Logs queries default to a limit of 500 and terms queries have a 500-result default that you raise with size (query editor).

FlatQL supports Elasticsearch 6 to 9 and OpenSearch 1 to 2 over the same HTTP API, with your credentials and nothing installed on the cluster. You write SQL. WHERE, ORDER BY, LIMIT and GROUP BY are pushed to the cluster as filters, composite aggregations and date histograms when they translate exactly; everything else, including joins, CTEs and window functions, runs in the embedded engine on up to about 50,000 rows per index per statement. Show as DSL displays the request Grafana's editor would have built for you, except that you arrived at it by typing SQL.

Comparison#

Where Grafana is the better fit#

• The question is the same every day. A dashboard of request rate, error ratio and p95 latency per service belongs in Grafana, refreshed on a schedule and visible on a wall.
• You need to be paged. Grafana's alerting creates alerts from query results (docs). FlatQL has no alerting.
• Elasticsearch is one of several sources. Grafana mixes Elasticsearch panels with Prometheus, Loki and others on one dashboard.
• You want logs tailing with a time picker and annotations overlaid on graphs.
• You are already paying for Grafana Enterprise or Cloud and want data source permissions and RBAC in the same place.

Where FlatQL is the better fit#

• The question is new. Explore is good for a quick aggregation, but when the answer needs a join, a running total or a ranking, SQL is faster to write than a chain of aggregation menus.

SELECT region,
       status_code,
       COUNT(*)                                        AS hits,
       SUM(COUNT(*)) OVER (PARTITION BY region)        AS region_total,
       ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (PARTITION BY region), 1) AS pct
FROM "logs-*"
WHERE "@timestamp" >= '2026-11-01' AND status_code >= 500
GROUP BY region, status_code
ORDER BY region, hits DESC;

The filter and the GROUP BY are pushed as a composite aggregation; the window function runs in the engine over the returned buckets. See GROUP BY in SQL.

• You need the rows, not the chart. Logs panels return 500 by default. FlatQL's grid pages through results and the export writes millions of rows to disk. See results and export.
• Two indices hold the answer. Joining orders to organizations or suppliers is a JOIN, not a dashboard transformation.
• The cluster is OpenSearch 1 or 2 or Elasticsearch 6 or 7.x below 7.17, which Grafana's data source does not list.
• You want per-index access control without an Enterprise licence. FlatQL's named roles grant read or write per index pattern on every request, with production connections read-only by default. See teams.
• You want a log of who ran which query, with duration and row count, grouped by statement fingerprint.

Using both#

The pattern that works: Grafana owns the dashboards and the pager; FlatQL owns the investigation. When a Grafana alert fires, someone opens FlatQL, writes the join that explains the spike, exports the affected order IDs to CSV and hands them on. If the query turns out to be useful every week, it gets rebuilt as a Grafana panel. Nothing in that loop requires either tool to do the other's job.

If you have been using Kibana for the investigation step, the Kibana comparison covers the same ground from that angle. For the cluster-administration side of operations, see the Cerebro comparison.

Note Grafana facts are from grafana.com documentation and pricing pages as of November 2026. Grafana Cloud prices are published usage rates and may change.