Turbopuffer vs. Manticore Search on a couple of cheap VPS
Turbopuffer vs. Manticore Search on a couple of cheap VPS
Author: Ilya Kuznetsov<br>Published: Jul 09, 2026 - 18 Min read
Serverless vector databases are marketed on a simple promise: you don't run anything, you don't tune anything, and someone else worries about storage, scaling and uptime. turbopuffer<br>is one of the better examples of the category: a fast search engine built on object storage, used by Cursor, Notion, Linear and others.<br>The promise is real, but it isn't free. So the obvious question is: for a small, well-defined workload, how much of that do you actually need, and what does the same workload cost and perform like on two cheap VPS running Manticore Search?<br>This article answers that with numbers from an apples-to-apples benchmark on the same dataset.<br>The workload<br>We took a concrete, modest workload, the kind a lot of real applications actually have, and sized turbopuffer for it:<br>ParameterValueDatasetDBpedia<br>(OpenAI embeddings)Stored documents975kVector dimensions1536 (cosine similarity)turbopuffer latency P50 / P90 / P99 (advertised, warm namespace)14 / 17 / 27 msturbopuffer estimated cost$75 / month (July 2026)The two turbopuffer numbers in that table are its advertised latency and its calculator-estimated cost, not measurements. The cost comes from turbopuffer's cost calculator<br>, and the latency is turbopuffer's published target: specifically the warm-namespace P50/P90/P99 from its own benchmark:
Two caveats come straight from that screenshot. First, those 14/17/27 ms are for a warm namespace; the same benchmark reports 874 / 1214 / 1686 ms for a cold one. A namespace that has aged out of cache is ~50–60× slower on its first queries, a direct consequence of turbopuffer's object-storage tiering. Second, turbopuffer's benchmark runs a different workload (1024 dimensions, 10M docs) than ours (1536 dimensions, 975k docs). turbopuffer's actually measured latency and throughput on our dataset are reported further down, and they differ from these advertised figures. Our benchmark dataset is 975k docs (DBpedia); both systems were loaded with the same data.<br>That $75/month comes straight from turbopuffer's own cost calculator for 1536-dim vectors with no attributes (the calculator's "Attributes: None"). This matches our benchmark, which was pure vector search: no stored attributes and no metadata filtering on either side. Both engines support attribute filtering and full-text search (Manticore also adds hybrid search<br>); we simply didn't exercise it here, so the comparison is like-for-like on plain KNN. The pricing is usage-based, and the breakdown is the interesting part:<br>ComponentRateThis workloadCostStorage≤ $0.33 / GB1M docs (~3 GB)$1.01Writes≤ $2.00 / GB10M writes, ~4 WPS (~61 GB)$61.44Queries≤ $1.00 / PB10M queries, ~4 QPS (~13 PB)$12.80Namespacesn/a100 × 10K docsIncludedTotal$75 / month (min $16 Launch plan)<br>The headline number is almost entirely writes: $61.44 of the $75 is the cost of ingesting ~61 GB of vector data, while storage (3 GB) is a rounding error.
The "~13 PB" against the query line looks alarming but is a billing abstraction, not bandwidth. turbopuffer meters queries by "GB queried" with a minimum billable of 1.28 GB per query, so the calculator simply computes 10M queries * 1.28 GB ≈ 13 PB. The data actually moving per query is tiny (a 1536-dim float32 query vector is ~6 KB in, a top-10 result is a few KB out), yet every query on a namespace this small just bills at the 1.28 GB floor. At ≤$1/PB that whole 13 PB costs only $13, so query pricing is trivial here.<br>This matters for the comparison because on a self-hosted engine none of these meters exist: writes are just CPU time, queries have no per-query floor, and there is no per-GB charge at all. (turbopuffer pricing<br>, pricing changelog<br>The contenders<br>turbopuffer is serverless for the user: storage lives on S3/GCS/Azure object storage (~$0.02/GB), with hot data tiered through NVMe and RAM caches. You never provision or patch a server, never manage replication, never do capacity planning. You pay per GB stored / written / queried, and query compute runs on turbopuffer's managed infrastructure rather than on hardware you provision.<br>Manticore Search is software you run yourself. For this comparison we used the cheapest realistic setup that still gives you redundancy:<br>ParameterValueNodes2 × Hetzner CX23 (region "eu-central") in a clusterCost per VPS$8.25 / monthCPU per VPS2 coresDisk per VPS40 GB (table data uses ~6 GB)Role of 2nd nodeReplica for redundancyManticore total cost$16.50 / month (or $8.25 for a single node if you don't need redundancy)Manticore stores vectors in an HNSW index (via the Manticore Columnar Library<br>) and supports scalar quantization (8-bit and 1-bit) with oversampling and rescoring to trade memory and speed against recall. For this test we used 1-bit (binary) quantization with oversampling=2.0 and rescoring, settings chosen specifically to land at...