# Kibana Sizing Guide?

**URL:** <https://discuss.elastic.co/t/kibana-sizing-guide/296395>\
**Category:** Kibana\
**Created:** [February 6, 2022, 1:57pm UTC](https://discuss.elastic.co/t/kibana-sizing-guide/296395 "2022-02-06T13:57:34Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![crpj](https://avatars.discourse-cdn.com/v4/letter/c/edb3f5/32.png) [@crpj](https://discuss.elastic.co/u/crpj)\
**Post date:** [February 6, 2022, 1:57pm UTC](https://discuss.elastic.co/t/kibana-sizing-guide/296395/1 "2022-02-06T13:57:34Z")

</div>

Hello, I am attempting to create a sizing estimate and did not find specific guidance for Kibana, could anyone clarify if there is an official guide? As of now, I am considering this setup to be a single machine:

- 4 CPUs
- 16 GB RAM
- Storage - not sure about this one, also I believe it does not need to be a SSD.

The use case is not completely defined yet but I would expect to have dashboards using aggregations over an index having 2M documents ingested per day, I am envisaging creating a Transforms job to send aggregated data to another index to make Kibana's life easier.

---

<div class="post-metadata">

**Author:** ![Tomo\_M](https://avatars.discourse-cdn.com/v4/letter/t/848f3c/32.png) [@Tomo\_M](https://discuss.elastic.co/u/Tomo_M)\
**Post date:** [February 6, 2022, 2:29pm UTC](https://discuss.elastic.co/t/kibana-sizing-guide/296395/2 "2022-02-06T14:29:52Z")

</div>

The post was from elastic team member. He says it is quite light weight.  
I suppose Kibana coexisting in Elasticsearch node could be a good start point.

> [@Kibana server sizing?](https://discuss.elastic.co/t/kibana-server-sizing/82366/2):
>
> It's pretty light weight unless you are using the Reporting functionality (which requires CPU). I'd just use a single CPU, 2GB at most.

---

<div class="post-metadata">

**Author:** ![crpj](https://avatars.discourse-cdn.com/v4/letter/c/edb3f5/32.png) [@crpj](https://discuss.elastic.co/u/crpj)\
**Post date:** [February 6, 2022, 3:42pm UTC](https://discuss.elastic.co/t/kibana-sizing-guide/296395/3 "2022-02-06T15:42:56Z")

</div>

Hi @Tomo_M

I did see this post before which got me thinking on the requirements needed since it will use the reporting features, I do not know for instance that "X" Number of dashboards running aggregation queries over an index with "X" documents demand "X" CPUs, "Y" Storage capacity and so forth. I agree with your approach as a starting point but was somewhat frustrated for not finding a clear guidance as we see for Elasticsearch here [https://www.elastic.co/pdf/elasticsearch-sizing-and-capacity-planning.pdf](https://www.elastic.co/pdf/elasticsearch-sizing-and-capacity-planning.pdf)

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [February 6, 2022, 9:36pm UTC](https://discuss.elastic.co/t/kibana-sizing-guide/296395/4 "2022-02-06T21:36:17Z")

</div>

That's nearly 5 years old @Tomo_M😉  
I would probably add a bit more resources to Kibana these days, as there's substantially more functionality and complexity to it.

Usually the limiting factor with sizing is going to be with Elasticsearch, not Kibana. I'd focus on that first.

---

<div class="post-metadata">

**Author:** ![Tomo\_M](https://avatars.discourse-cdn.com/v4/letter/t/848f3c/32.png) [@Tomo\_M](https://discuss.elastic.co/u/Tomo_M)\
**Post date:** [February 7, 2022, 4:44am UTC](https://discuss.elastic.co/t/kibana-sizing-guide/296395/5 "2022-02-07T04:44:51Z")

</div>

Thanks @warkolm 😀

@crpj At least, the number of documents in index to be aggregated has no effect on Kibana node sizing. And also just existance of dashboards doesn't matter without reporting.

If you feel frustrated by slow rendering, Kibana is just waiting for the response from Elasticsearch cluster. Even if you enhance the Kibana node, dashboard rendering will not speed up in most cases.

To speed up dashboards, transform is a good strategy. Transform can do the heavy aggregation in Elasticsearch cluster in advance.

In my opinion what affects Kibana sizing should be the number of simultaneous connetions, the enthusiasm for editing the dashboards, the number of accesses to the shared dashboard, etc. I agree that it is nice if there are some guidence for kibana sizing in official document (even if it is not as clear as that of Elasticsearch).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [March 7, 2022, 4:45am UTC](https://discuss.elastic.co/t/kibana-sizing-guide/296395/6 "2022-03-07T04:45:49Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
