.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Kibana is the user interface for Elasticsearch. It talks to Elasticsearch and to nothing else. Grafana sits one layer up from about twenty different backends, querying them and drawing the results, storing nothing itself.
That structural difference drives every practical answer below. The two get compared because they both draw charts in a browser, which is about where the similarity ends.
The useful version of the question is what your primary data is. If it is log lines you need to search by content, one answer wins. If it is numbers over time from several places, the other does. Plenty of teams run both, pointed at the same cluster, and that is a legitimate setup.
What Kibana is tied to
Kibana is a Node.js application that renders Elasticsearch. It ships as part of the Elastic Stack and its version has to match your Elasticsearch version, so upgrades are a coordinated exercise across both. As of late August 2026 both projects are on the 9.5 line, with 8.19 still under extended maintenance.
What you get for that coupling is depth. Discover gives you full text search across indexed fields with filtering, field statistics and saved searches. Lens builds visualisations by dragging fields. Elastic's query languages, KQL for filtering and ES|QL for the newer pipe-based analysis, are designed against the same index Kibana is reading. Alongside that sit machine learning jobs, index lifecycle management, security and observability apps, plus a data view layer that understands your mappings.
None of that transfers to any other data source, because there is no other data source. If half your numbers live in Postgres and the other half in Prometheus, Kibana has nothing to say about them.
What Grafana is tied to
Nothing, and that is the whole product thesis. A small database of its own carries the dashboards, the folders and permissions, the accounts, the alert rules and the data source definitions, and every value on screen is fetched live from wherever it lives. One dashboard can put a Prometheus counter, a Loki log volume chart and a PostgreSQL business number on the same row, sharing one time picker.
The price of that agnosticism is shallowness on any specific backend. Grafana's Elasticsearch data source is good and it is not Kibana. No Discover, no field statistics sidebar, no Lens, no index management. It is a query interface, and administering the cluster happens somewhere else.
Pointing Grafana at your existing Elasticsearch cluster
You do not have to pick a front end. The Grafana Elasticsearch data source supports 7.17 and later, 8.x, 9.x and Elastic Cloud Serverless, and Grafana's maintenance policy for it tracks Elastic's own end of life dates. You get Lucene query syntax for log queries, bucket and metric aggregations for numeric panels, raw Query DSL in code mode, ES|QL queries, annotations and alerting on query results.
If you run Amazon OpenSearch Service, use the separate OpenSearch data source. The docs say so explicitly and the two have diverged enough that the wrong plugin produces confusing failures rather than clean errors.
The combination is the right call when your logs are already in Elasticsearch, the log-focused people are happy in Kibana, and you also need dashboards that mix those logs with metrics from somewhere else. Run Kibana for search and investigation. Run Grafana for the wall dashboard and the alerting. Both read the same cluster, Kibana users keep Discover, Grafana users get one time range across four backends, and nobody migrates anything.
It is the wrong call when you are adding Grafana purely to get prettier charts over Elasticsearch data. That buys a second service to maintain in exchange for less capable Elasticsearch tooling. Fix the Kibana dashboard.
Loki or Elasticsearch as the log store underneath
Index strategy is what separates them, and the decision sits one layer below the front end.
Elasticsearch is an inverted index over your document contents. Every analysed field is tokenised and indexed at write time, which is what makes arbitrary full text search across terabytes fast. You pay for it twice: in disk, because the index frequently rivals or exceeds the size of the raw data, and in RAM, because query performance depends on the JVM heap and the filesystem cache having enough room to work.
Loki takes the opposite bet. The Loki overview puts it directly: Loki does not index the contents of the logs, but only indexes metadata about your logs as a set of labels for each log stream. Chunks are compressed and pushed to object storage. A small index and highly compressed chunks are what make it cheap to run.
At the keyboard, that shows up like this. In Elasticsearch, searching a rare string across everything from last month is fast and always was. In Loki, the same query selects streams from labels and then brute-force scans the matching chunks, so it is fast when your label selector is tight and slow when it is not. LogQL pushes you toward filtering by application and environment first, then grepping inside. People coming from Kibana notice the difference in the first week.
I cannot fully account for the variance in that second case. The same wide-selector query over the same data is sometimes fine and sometimes takes ninety seconds, and the chunk cache is presumably involved somewhere. I plan around it instead of understanding it, which is not a satisfying place to leave a paragraph.
If searching log content is the daily job, security investigation, auditing, debugging by grep across services, take Elasticsearch and take Kibana with it. If logs are context you open after a metric alert fires, take Loki, because it costs a fraction of the disk and a fraction of the RAM for that pattern. Working out where your logs are before you move them is a different question, and it is covered in finding Grafana's own log files, which is the first thing people ask anyway. That one is about Grafana's logs rather than your application's.
Alerting and notification channels
Grafana OSS gives you unified alerting with no feature gating. Alert rules across any data source, contact points for email, Slack, PagerDuty, webhooks and several dozen more, notification policies, silences, mute timings and templated messages, all in the free build. Configuring the email path is the only part that needs work, since self-hosted Grafana has no mail relay of its own, and sending alert emails from Grafana walks through the SMTP block and the contact point together. Budget half an hour.
Kibana's alerting is tiered. Rules exist in the free Basic tier, and connectors are where the line sits. Elastic's own subscription comparison, checked on 26 August 2026, lists Basic as including Elastic connectors such as Server log and Index, with the third-party connectors sitting in Gold and above. Elastic's connector reference states the general rule as some connector types being paid commercial features while others are free. Check it against your own subscription rather than taking my word for it, because the tier names move.
Translated: a self-managed free Kibana can raise an alert and write it to an index or a log file. Getting that alert into an inbox or a chat channel is a paid feature. Watcher exists in Basic and can be scripted around this, and plenty of people do, but it is JSON in a text editor rather than a UI. If you are self-hosting on a free licence and need notifications, Grafana wins this section outright, and it is not close.
Licence history: Elastic, OpenSearch and AGPL
In January 2021 Elastic moved Elasticsearch and Kibana off Apache 2.0 to a dual SSPL and Elastic License 2.0 arrangement, which is source-available rather than open source by the OSI definition. AWS forked the last Apache-licensed release, 7.10.2, and shipped it as OpenSearch and OpenSearch Dashboards under Apache 2.0. In September 2024 that project moved to the Linux Foundation as the OpenSearch Software Foundation, and it has since released its own 3.x line rather than tracking Elastic's.
Then Elastic changed course. The August 2024 announcement added AGPLv3 as an option for Elasticsearch and Kibana alongside ELv2 and SSPL, with Shay Banon describing it as simply adding another option and not removing anything. Current Elasticsearch and Kibana can therefore be used under AGPLv3, the same licence Grafana itself has carried since version 8.0.
Practical upshot in 2026: the licence objection to Kibana has mostly gone away, and if your policy blocks AGPL you have a problem with Grafana too. OpenSearch Dashboards remains the Apache 2.0 answer for organisations that need permissive licensing, and it now has a genuinely independent project behind it rather than being a vendor fork in a holding pattern.
Resource footprint on a single VPS
| Component | What drives its memory | What I budget on a single VPS |
|---|---|---|
| Grafana | Concurrent dashboard rendering | 512 MB, the documented minimum, and it holds |
| Prometheus | Active series count | 1 GB for a few thousand series |
| Loki, single binary | Ingestion rate and chunk cache | 1 GB for a handful of hosts |
| Elasticsearch, single node | JVM heap plus filesystem cache | 4 GB minimum, 8 GB before it stops being irritating |
| Kibana | Node.js heap, fairly flat | 1 GB |
The Grafana figure is documented: minimum recommended memory 512 MB, minimum recommended CPU one core. The Elasticsearch figure comes from how the JVM is sized. Elastic's JVM settings reference says to set Xms and Xmx no higher than 50% of the total memory available to the node, with the minimum and maximum equal, and to stay under the compressed object pointer threshold, which it puts at a safe 26GB on most systems. The half-the-RAM rule is the important half. Whatever heap you give Elasticsearch, the box needs roughly the same again for the filesystem cache that makes searches fast.
So a full Elastic Stack on a 2 GB VPS is a bad time. It starts, it indexes for a while, then the JVM spends its life in garbage collection and Kibana times out waiting. Grafana plus Prometheus plus Loki on that same 2 GB box is unremarkable and will run for months. If you want that stack up quickly, running Grafana with Docker Compose puts all three in one file. The compose file is short enough to read in one go.
Disk follows the same pattern. Elasticsearch indexes are frequently comparable in size to the raw logs, sometimes larger with default dynamic mappings. Loki chunks compress hard. On a VPS with fixed NVMe rather than an expandable volume, that ratio decides how many weeks of logs you get to keep.
Which to pick by primary use case
Take Kibana when log search is the job. Security work, audit trails, debugging by searching arbitrary strings across services, anything where you do not know in advance which field you will need to filter on. Take it with the RAM to run Elasticsearch properly, and budget for the Gold tier if free-tier notification limits block you.
Take Grafana when time series come first and your data is spread out. Infrastructure and application metrics, mixed sources on one dashboard, alerting that reaches a human without a paid connector, plus any setup where the monitoring stack has to fit on a small server alongside other things. Installing Grafana on Ubuntu has the install path. On a fresh box it is about twenty minutes including the reverse proxy.
Take both, reading the same Elasticsearch cluster, when the cluster already exists and different people need different things from it. This is the most common ending in teams above about fifteen engineers, and it costs you one extra small service rather than a migration.
Take OpenSearch with OpenSearch Dashboards when you need Apache 2.0 licensing specifically, or you are on AWS and the managed service is the path of least resistance.
If the front end is not what you are unhappy with, Grafana alternatives covers the wider set of options, and the complete Grafana guide covers running this one properly. None of these is a one-way door. Both front ends read the same cluster, and you can add the second on a Thursday and remove it on a Friday.
