Benchmarks
Numbers only get published here once they can be reproduced by someone other than us, following the methodology below.
We publish an official number here only once it can be reproduced by someone other than us — hardware, dataset, and query mix fully disclosed, following the full methodology further down this page. Until then, see the preliminary comparison below for a directional, fully-disclosed data point. See the Roadmap for where the benchmark suite stands.
Preliminary comparison (informal, single run)
This is not the reproducible, published benchmark suite described below — that is still an open item on the Roadmap. It is one ad hoc run against Tachyon vs. Typesense, done in a single sitting on a laptop, with no repeated trials and no concurrency sweep. It's published here anyway, fully disclosed, because a directional data point with its limitations stated is more useful than no data point. Treat every number below as informal until it's superseded by the real suite.
Fully disclosed below — laptop model, chip, host RAM, and the Docker Desktop VM's CPU/RAM allocation.
Corpus size, document shape, and generation method documented below. Synthetic only.
Both engines ran on default configuration; the flags used are listed below.
Pinned to a Docker image tag and digest, not a specific Tachyon commit or release.
One blended pool of plain-text queries. No separate filtered, faceted, or sorted numbers.
Single client, sequential requests only. No throughput or latency-under-load figures.
Hardware
MacBook Air, Apple M4, 24 GB unified memory, macOS 26.5.2. Both containers ran through Docker Desktop 29.7.2 (Linux VM, kernel 6.12.76-linuxkit), which had 10 CPUs and 7.75 GiB RAM allocated — that VM allocation, not the full host, is the effective ceiling both engines ran under. One engine ran at a time; they never competed for resources with each other, but ordinary background activity on the host was not suppressed or controlled for.
Software under test
adikeshri/tachyon:latest (digest sha256:92a0dd9b…0445dd) vs. typesense/typesense:30.2 (digest sha256:610f2d34…c1e110), the latest stable Typesense tag at the time — 31.0 existed only as a release candidate. Not a commit-pinned Tachyon build, which the methodology below requires; the published image tag is the closest substitute used here. Both ran with default configuration: no non-default flags for Tachyon; Typesense was started with only --data-dir and --api-key. Typesense's default response highlighting was left on and Tachyon has no highlighting feature to disable — the two are not doing identical work per query, and that gap is not backed out of the latency numbers below.
Dataset
Synthetic product-catalog documents — title, description, brand (faceted keyword), price (filterable/sortable int) — generated from a fixed vocabulary and a fixed random seed, roughly 150–250 bytes per document. The same generated corpus, and the same document ids, were reused for both engines and all three sizes: the 1M run is the first 1,000,000 lines of the same file the 5M run reads in full. No real-world data was used, and no field this small stresses long-document tokenization or storage the way a real catalog with longer body text would.
Query mix and concurrency
500 queries, drawn from the same fixed vocabulary as the corpus so every term actually appears in it: 150 single-word product-noun queries, 100 single-word adjective queries, 150 two-word adjective+noun queries, and 100 brand+noun queries, in a fixed random order reused across both engines and all three sizes. No filters, facets, or sort clauses were exercised — every query was a plain text search. All 500 ran sequentially from a single client over one persistent connection; the first 5 were discarded as connection/cache warmup and excluded from the latency figures below. Nothing here measures throughput under concurrent load or query types other than plain text search — both are open gaps against the methodology below.
How memory was measured
Real per-process resident memory, read from /proc/<pid>/status inside each container — not docker stats, whose container-wide cgroup figure includes reclaimable page cache and understates how an mmap-based engine like Tachyon actually behaves. Peak is the highest reading sampled once a second across ingest and the full query run. Steady is a reading taken about five seconds after the 500 queries finish — deliberately after query traffic, not right after ingest, so it reflects working-set memory once the collection has been touched by realistic reads rather than a cold snapshot.
Results
The better-performing value in each row is highlighted in green.
| Metric | Tachyon | Typesense 30.2 |
|---|---|---|
| Ingest time | 0.99s | 1.57s |
| Ingest throughput | 101.3K docs/s | 63.6K docs/s |
| Memory, peak | 24.2 MiB | 367.1 MiB |
| Memory, steady | 24.2 MiB | 343.3 MiB |
| Disk size | 56.2 MiB | 40.8 MiB |
| Search latency, best case | 1.00 ms | 1.82 ms |
| Search latency, p95 | 4.01 ms | 5.41 ms |
| Search latency, p99 | 4.84 ms | 6.62 ms |
| Search latency, worst case | 6.16 ms | 8.89 ms |
| Metric | Tachyon | Typesense 30.2 |
|---|---|---|
| Ingest time | 11.73s | 18.25s |
| Ingest throughput | 85.3K docs/s | 54.8K docs/s |
| Memory, peak | 108.3 MiB | 486.8 MiB |
| Memory, steady | 108.3 MiB | 462.9 MiB |
| Disk size | 590.7 MiB | 444.5 MiB |
| Search latency, best case | 3.76 ms | 4.30 ms |
| Search latency, p95 | 11.07 ms | 17.61 ms |
| Search latency, p99 | 19.42 ms | 19.55 ms |
| Search latency, worst case | 25.55 ms | 44.73 ms |
| Metric | Tachyon | Typesense 30.2 |
|---|---|---|
| Ingest time | 79.74s | 105.41s |
| Ingest throughput | 62.7K docs/s | 47.4K docs/s |
| Memory, peak | 426.7 MiB | 995.1 MiB |
| Memory, steady | 426.3 MiB | 944.7 MiB |
| Disk size | 2875.6 MiB | 1764.6 MiB |
| Search latency, best case | 15.60 ms | 15.28 ms |
| Search latency, p95 | 38.98 ms | 89.12 ms |
| Search latency, p99 | 65.16 ms | 101.69 ms |
| Search latency, worst case | 106.39 ms | 280.02 ms |
Directionally: Tachyon ingested faster and used substantially less memory at every size tested, with Typesense's baseline single-node consensus overhead (~200–300 MiB before any data is loaded) a large part of the gap at 100K documents specifically. Tachyon's on-disk footprint was larger than Typesense's at 1M and 5M documents — it trades disk space for the lower memory use. None of this should be read as a substitute for the real benchmark suite below; it's a single, fully-disclosed data point.
Planned dataset sizes
Where technically feasible, each benchmark will be run at:
Methodology
The exact instance type, CPU, memory, and disk used for every run will be published alongside the numbers — not just described in prose.
Corpus size, average document size, field cardinality, and where the dataset itself comes from (synthetic vs. real-world) will be documented per benchmark.
Separate numbers for single-term, multi-term, filtered, faceted, and sorted queries — a single blended average hides too much.
Latency and throughput reported at a range of concurrent client counts, not just a single-client best case.
Every non-default flag used for a run (memtable size, merge thresholds, sync interval) will be listed — configuration changes performance.
Each result set will be pinned to a specific Tachyon commit or release, so numbers don't silently drift out of date.
Comparisons
Once Tachyon's own numbers are published, comparative benchmarks will follow the same rule: same hardware, same dataset, equivalent queries, documented configuration for every system under test, no cherry-picked results.