Benchmarks

This page says what we measured, on what, and what we have not measured yet. None of it is a service level.

• Production was measured on 2026-11-04 on Logthread's production service in Mumbai.
• Development stack was measured on 2026-11-03 on one developer laptop. It shows what the software does with more CPU than production has today.

The raw results (JSON) are available on request.

Production (2026-11-04)#

What it ran on#

• Service: Logthread production, Mumbai. One Ampere Arm server with 2 cores and 12 GB, running the gateway, the worker and the database. The managed queue is Oracle Cloud Queue, and the production storage and query layer is used throughout.
• Workspace: a scratch workspace on the Enterprise plan. Its plan limits did not stop any run.
• Load generator: Logthread's load generator on a laptop in the United States, about 250 ms from Mumbai. Query times include that round trip, about 1 s per call (the "Repeat" column shows it).
• Records: OTLP or NDJSON logs, gzip, about 155 bytes per record before compression.

Results: ingest#

On this server the end-to-end rate it sustains (accepted, processed and stored) is about 5 MB/s, about 18 GB per hour. Short bursts up to about 10 MB/s are absorbed by the queue and caught up within minutes. The limit is the server's CPU. More or larger servers raise it; enterprise capacity is provisioned per contract.

Results: ingest lag at 10 GB per hour#

Time from the gateway acknowledging a record until the search API returns it, during the 1-hour run. 330 probes, 0 failed.

Results: query latency at 10 GB per hour#

13.8 million rows in the last hour and 95.9 million in 24 hours. 20 runs per cell, each a different statement so none comes from the result cache. Every time includes about 1 s of round trip from the United States.

The 30-day cells were not completed: the run reached the workspace's hourly read allowance (1 TB read per hour), which the benchmark's own repeated 24-hour and 30-day queries had used up. Each 24-hour query over this volume reads 1 to 3 GB.

Development stack (2026-11-03)#

What we measured#

"MB/s" in the ingest results is the uncompressed OTLP size, not the size on the wire. A request is gzip-compressed, so the network carries roughly a sixth of it.

What it ran on#

• Machine: Apple M4 Max, 16 cores, macOS. Docker Desktop with 16 CPUs and 7.7 GiB of memory for containers.
• Stack: Logthread's development stack. One ingest container running the gateway, worker and redrive roles together, Valkey as the queue (two queues), Postgres, one web container, one jobs container. Containers are linux/arm64.
• Load generator: Logthread's load generator, on the same machine. It competes with the stack for CPU.
• Workspace: Enterprise plan, with its ingest rates (100 MB/s sustained, 1,000 MB burst). The limits are not what stopped any run below.
• Storage and query layer:
• For the ingest run, the storage write path was replaced by a stand-in that accepts and discards writes. This measures the gateway, the queue and the worker, with no storage cost.
• For lag, query, alert, dashboard and SLO numbers, the real storage and query layer was used, over the internet, from a development workspace. It is shared with other development workloads, so counts include data that is not ours, and its load varies.
• Data in the workspace: about 2.8 million rows in 30 days (1.1 million in the last hour, 1.3 million in 24 hours). The 30 day window is the workspace's whole retention. Over 200,000 of the rows were loaded with the backfill option, spread over the past 30 days.

Results: ingest throughput (gateway, queue and worker)#

Records go through the gateway, the queue and the worker, and are delivered to a stand-in that discards them. No request was throttled, rejected or dropped.

Every step was sustained. The queue was empty at the end of the last step, so the worker kept up with the burst.

The highest rate we reached on this machine was about 97 MB/s (about 630,000 records/s). That was a separate short run with no rate limit and 32 workers. At that rate the ingest container used about 760% CPU and no request was throttled. We did not find out whether the limit was the container, the Docker VM or the load generator, so treat 97 MB/s as a ceiling of this setup, not of the software.

Results: ingest lag#

Time from the gateway acknowledging a record until the search API returns it. 30 probes, 0 failed, with 0.5 MB/s of background load.

The search was polled about every 0.6 s, so each figure is accurate to about that much. The table is from a run without storage problems. While the storage layer refuses writes, records wait in the queue and lag grows; see Storage outage for how quickly delivery resumes.

Results: query latency#

Rows in the window are the whole workspace. "Repeat" is the same statement asked again straight away, which is what a second viewer of the same dashboard sees.

With 20 runs per cell, p95 is close to the slowest run. These workspaces hold millions of rows, not the billions an Enterprise customer will have, so do not extrapolate the 30 day figures.

Results: alert evaluation delay#

Rule: count above 0 for a marker, window 5 minutes, evaluated every minute. 5 trials, all fired.

Most of this is the wait for the rule's next evaluation, which depends on where in its minute the records arrive. With 5 trials a p95 is not meaningful, so we show the maximum.

Results: dashboard refresh#

The panel query a dashboard runs on every refresh, one panel at a time, 20 refreshes 6.5 s apart (so each is past the 5 s live cache).

One panel was measured at a time. A dashboard with many panels was not.

Results: SLOs#

A save measures the SLO over its window and breaks the bad requests down before it answers; the two run at the same time, and the breakdown is skipped if it takes longer than 6 seconds. (The first run, before they ran together, measured 6.5 s at p50.)

Results: storage outage#

Ingest at 2,000 records/s while the storage write path answered every request with 503 for 60 seconds, then recovered.

During the outage records wait in the queue; the worker backs off and probes once per tenant until a write succeeds. When the storage layer sends a Retry-After, the worker waits that long (at most 15 minutes) before probing again.

Timestamps#

The gateway does not reject old records. A record keeps the time it carries, so history can be loaded. Only a record more than 24 hours in the future is given the time it was received. The 30 day cells above rely on this: 99,500 records spread over 30 days were all searchable.

What is not measured yet#

Do not read any number above as a claim about the following.

• The Enterprise rates. Production today sustains about 5 MB/s end to end on one server, not the Enterprise plan's 100 MB/s with 1,000 MB bursts. Enterprise capacity is provisioned and agreed per contract.
• More than one server. Every production run used the single server. Scaling out is prepared but was not measured.
• Many tenants at once. All runs used one workspace.
• Large data. Query numbers are for up to about 100 million rows, not billions.
• Duration. The longest run was one hour. No soak over days.
• Alerts, dashboards and SLOs on production. Those numbers are from the development stack only.
• A customer's network. Production query times include the round trip from the United States to Mumbai; a customer elsewhere sees a different round trip.
• Failure behaviour at high rate. The outage test ran on the development stack at 2,000 records/s, and only one kind of failure (storage refusing writes) was tested.

Reproduce#

The benchmark harness drives Logthread's own load generator and public APIs. It needs only an ingest key, an API key with the read, alerts and dashboards scopes, and a member's sign-in for a scratch workspace. It never prints credentials, and it deletes the alert rules and SLOs it creates (log records expire with the workspace's retention). To see these numbers on your own workload, ask us to run it against a scratch workspace in your account; we share the raw results.