Small Elasticsearch, honestly
Versions checked on 26 October 2026 for Elasticsearch 9.5.5 and OpenSearch 3.9.0; lab status is given per page below. Configs: github.com/jtsunne/small-elasticsearch-lab at v0.1.0.
A guide to running Elasticsearch 9.5.5 or OpenSearch 3.9.0 yourself on small machines: 1 to 4 CPUs, 2 to 16 GB of memory, Docker Compose, one to three nodes. It is for the person who has to keep such a node running, often alone, and wants to know what is documented, what was actually tried, and what is a guess.
What it is not: no Kubernetes, no Elastic Cloud or other hosted service, no OS packages, no benchmarks of big hardware.
How to read it
Every number and claim carries its basis:
- official: from the vendor’s documentation, linked.
- measured: observed in my lab run, with the row id or log that shows it.
- rule of thumb: common practice, not checked here.
- estimate: my arithmetic, shown.
- not measured: a gap, said out loud.
Where I did not test something, the page says so in a “Not tested” list.
The lab behind it
Every config on these pages is a file from the public companion repo, small-elasticsearch-lab (code under MIT, results and prose under CC BY 4.0). It holds the compose files, Caddyfiles and scripts for each scenario, the checks they must pass, and the raw results. The pages were tested at the tag v0.1.0, and every file link on them points at that tag.
All of it was tested on one laptop: Linux with cgroup v2, 12 logical CPUs, about 15.5 GiB of RAM, Docker containers limited to 1 CPU and 2 GiB per node. One laptop run is one data point, not a reference. Three nodes on one host show how quorum works, not how a real cluster survives hardware failure.
| Page | Lab status |
|---|---|
| Sizing a small node | not published: the benchmark runs are not done |
| Minimal security, with Caddy in front | tested on 29 October 2026, Elasticsearch and OpenSearch |
| One node or three | tested on 29 October 2026, Elasticsearch only |
| OpenSearch, snapshots and upgrades, operating | not written yet |
Key numbers
The official values every page relies on. The line under the title gives the date they were checked.
| What | Value | Basis |
|---|---|---|
| Automatic heap, Elasticsearch node with more than 1024 MB of memory | 50% of memory, at most 31 GB | [official] |
| OpenSearch default heap when not set | 1024 MB | [official] |
| Disk watermarks, low / high / flood stage | 85% / 90% / 95% of the filesystem holding path.data | [official] |
| Shard limit per data node | 1,000 | [official] |
| Target shard size | 10 to 50 GB | [official] |
vm.max_map_count, Elasticsearch | 1048576 | [official] |
vm.max_map_count, OpenSearch | 262144 | [official] |
| Kibana container memory, official compose / recommended with alerting | 1024 MB / 2048 MB | [official] |
| Off-heap memory per node assumed by the sizing model | 400 MB | [estimate] |
| Documents per GB of disk | not measured yet | [not measured] |
Pages
| # | Page | What it answers |
|---|---|---|
| 1 | Minimal security, with Caddy in front | A single node with authentication and no certificates, Caddy for TLS and request filtering, and roles and API keys as the real access control. |
| 2 | One node or three, and growing from one to three | When one node is enough, why two is the worst number, and how to grow a single node into three without losing data. |