Atomix stores logs compressed 8 to 59 times, searches them in place and raises alerts on 24 rule types. One server does the work of an Elasticsearch cluster and keeps a year of logs on a disk you can afford.
Search, dashboards, detection, threat intel and alert triage in one product. Pick an area to see it.
Type a word or a KQL filter. Counts and the histogram come from the column index, so a month of logs answers before you finish reading the query.
Where Atomix replaces a bigger, costlier stack.
Ingest-based pricing punishes the logs you need most. Atomix stores them for a fraction of the disk, on hardware you choose.
One deployment, many organisations, each with its own users, keys, rules and retention.
Offline builds, local storage, audit logs and no data leaving the site.
No shards, no JVM heaps, no replica maths. One server, one data directory, one backup.
Four work streams, numbered in the order they are planned to ship. None of them is available yet.
Alerts already carry the evidence. Playbooks will act on it: enrich, notify, open tickets, isolate a host, and wait for an analyst's approval when it matters.
A small agent for Windows, Linux and macOS that ships logs straight into Atomix, registers itself, and takes its configuration from a profile you manage centrally.
Ask for what you want in plain language and get the KQL. Let the system group the noise so analysts look at clusters, not thousands of identical events.
Today Atomix runs on one server. The next step is several: ingest and query nodes that share storage, so a failed machine means a restart, not a gap in your logs.
Pick a size or set your own numbers. The spec comes from measured ingest and search costs; the prices are list prices from , and the same workload is sized for Elasticsearch so you can compare.
About vCPU in total. Elastic Cloud (hosted) for the same hot nodes: a month depending on the rate card, with storage included in the node price.
| Provider | Atomix server | Atomix | Elasticsearch nodes | Elasticsearch | Lower by |
|---|
Atomix. Raw logs per day = EPS × event size × 86,400. Stored = raw ÷ compression ratio. Local disk = stored × local days × 1.3, plus 21% of what moved to object storage (the column index stays local so counts and charts stay instant). CPU and RAM come from a table of measured tiers: ingest and compaction cost about 0.1 core per 1,000 EPS of 1 KB events, and the rest is search headroom. RAM is at least one day of stored data for the file cache.
Elasticsearch. Disk = raw × (local + object days) × index factor × (1 + replicas) × 1.25 for disk watermarks. The days Atomix keeps on local disk go on hot nodes at 1 GB of RAM per hot disk GB; the days it keeps in object storage go on warm nodes at 1 GB per warm disk GB, as Elastic's hot-warm architecture would do. At least 3 nodes. Each node is a 64 GB machine with a 31 GB JVM heap. Elastic's frozen tier with searchable snapshots would lower this further for very long retention, but it needs an Enterprise licence. The Elastic Cloud range multiplies the cluster's RAM by two published Standard-tier rates.
Prices. List prices, monthly, no commitments or discounts, converted to USD where needed. Each provider gets the smallest plan that meets the CPU and RAM, plus extra disk at the provider's block or network storage rate, plus object storage for the warm tier. Software licences are not included on either side.
Sources (checked November 2026; prices change, so verify before you buy):
The same 1,000 events per second kept for 90 days. Measured figures for Atomix; Elastic's own sizing rules for Elasticsearch.
Disk and RAM bars are to scale. Elasticsearch figures use one replica, a 1.1× index and 1 GB of RAM per 30 GB of hot disk; change them in the calculator above.
Put your events per second and retention into the calculator and compare the server with an Elasticsearch cluster for the same workload.