Infino
talk to an engineer sign up

Pricing methodology

· open the calculator

The calculator is a monthly capacity estimate. It applies the same document count, write volume, query volume, result count, and payload assumptions to Infino and the alternatives shown for the selected query type. Hover totals show the resulting bill lines; the assumptions and sources follow below. Note that Infino estimates are Infino Cloud only; Enterprise accounts have different pricing.

How to read these numbers

Treat these totals as directional capacity estimates. Equivalent production performance depends on the real schema, compression ratio, query mix, filters, latency target, traffic peaks, region, support plan, and negotiated agreement. Vendor products and prices also change. Confirm a production estimate with each vendor before making a purchasing decision.

A small hot working set that fits a low-cost always-on instance will show smaller differences across systems. Larger differences tend to appear on bigger data sets with periodic query traffic, where object-storage retention and selective reads avoid keeping the full corpus hot.

Infino rates are Infino Cloud prices, August 2026. Alternative rates are public list prices available in August 2026 unless stated otherwise. Private offers, annual commitments, cloud credits, reserved-instance discounts, support contracts, and taxes are excluded.

How alternatives are sized

Each alternative is the lowest-cost public list-price deployment that a senior engineer could reasonably choose for production: one that can hold the data and serve the sustained query rate, using the replication and availability the vendor documents. A row is omitted when the published product range cannot cover the workload, for example when one Postgres node cannot hold the working set.

Query capacity is a per-engine density: retrieval work per second per vCPU. A cluster’s query capacity is that density times its vCPU count. Postgres, ClickHouse, Snowflake, and Databricks all go through that function. Infino is 17.5 RT/s per vCPU, and every SQL density is that figure scaled by the engine’s measured ratio to it on ClickBench: ClickHouse 32, Snowflake 13, Databricks 8. Postgres stays at 2 RT/s per vCPU because it is a row store. Warehouse T-shirts are how Snowflake and Databricks sell that compute: X-Small is 8 vCPU and 2X-Small is 16 vCPU on the published size ladders, so the same vCPU need can pick a published credit or DBU SKU. The quantity compared across engines is vCPU-seconds of work per query, not wall-clock latency; a warehouse that answers later on a larger cluster has not necessarily spent more CPU doing it.

SQL ingest is priced two ways, because the vendors charge for it two ways. The CPU to ingest is a per-engine density taken from the load time ClickBench publishes beside every result — seconds to load the same 74 GB of source data on the same hardware, where ClickHouse takes 308 seconds and Postgres 937. That CPU shares the serving cluster rather than running beside it, so on a cluster already sized for queries it is often absorbed. On top of it, each vendor’s own ingest meter is billed at its published per-GB rate: ClickHouse Cloud lists ClickPipes as one of the four things it bills for, at $0.04 per GB received from the source; Snowflake charges Snowpipe at 0.0037 credits per GB, on uncompressed size for text; and Databricks charges Zerobus Ingest at $0.050 per GB on AWS at the Premium tier, the same tier its DBU rate here comes from. All three are list, so the 50% Zerobus promotion running to September 2026 is not applied.

Full-text ingest is a density in the same way, but ClickBench loads a 105-column analytics table and never indexes a document, so the rate comes from each vendor’s own indexing benchmark instead. Elastic’s sizing guide reports 62,000 events per second on 3 8-vCPU nodes for Metricbeat documents averaging 1.09 KB. AWS publishes r6g.4xlarge.search indexing speed directly in MiB/s beside its OR1 results — 1.6 KiB log documents, six cluster shapes between 148 and 260 MiB/s. Both are means across published runs rather than the best row.

Two adjustments turn those figures into a rate this calculator can apply. Each is stated per copy of the data, because Elasticsearch and OpenSearch index every document on the primary and again on every replica: Elastic ran without a replica and AWS ran with one, so the two only mean the same thing once normalised. And each is de-rated to a throughput the cluster can hold. AWS reports its r6g rows at 88–95% CPU as triggering admission control and rejecting documents, and names below 80% sustained as the target; Elastic publishes no CPU but describes its figures as the point where the node queues and then rejects. Taking the gap between AWS’s in-bound and out-of-bound rows as the cost of that headroom gives 2.45 and 2.91 MB/s per vCPU per copy. That the two land within 16% of each other, from different vendors on different hardware with different corpora, is the check that neither was read wrong. Elastic then pays that rate in each of its two zones and OpenSearch in each of its three copies.

Vector and hybrid ingest are read the same way, from the time each vendor publishes to build an HNSW graph rather than to append rows. Qdrant’s single-node benchmark gives upload-and-index times on an 8-vCPU server, and Supabase’s pgvector 0.6.0 results give them on a 16-core instance with the whole box building the index. Both are means across the published configurations rather than the fastest one, and both are per copy, so each of Qdrant’s replicas pays it. That gives 1.36 MB/s per vCPU for Qdrant and 0.87 for pgvector — an order of magnitude below full-text indexing, because building the graph means comparing each new vector against many existing ones rather than adding terms to a list.

Only runs between 960 and 1536 dimensions are used, which brackets the 1024-dimension embedding this calculator prices. The rate is not constant across dimensionality: graph construction spends its time on distance comparisons, whose cost scales with dimensions, on top of a per-vector cost that does not. Qdrant’s own runs show the split, indexing about 0.2 MB/s per vCPU at 96 and 100 dimensions against roughly 1.3 at 960 and 1536, so a low-dimension corpus is not evidence about a high-dimension one. Hybrid additionally counts the vector alongside the document, since the build processes both; vector mode does not, because there the document is the embedding.

The rate is per byte rather than per document, and the same pair of benchmarks decides it: AWS’s documents are 47% larger than Elastic’s, and it is the per-copy byte rates that agree while the per-document rates sit more than twice as far apart.

When a density comes from a published benchmark, it is applied only to clusters at least as large as the hardware that produced the number. Smaller starting SKUs retain their documented capacity. A vendor may still recommend a different topology after benchmarking the actual workload.

Workload inputs

  • Storage. Documents retained at the end of the month, and never fewer than the month’s writes: a month of ingest has to land somewhere, and a corpus holding a fraction of what it takes in would price ingest against a cluster too small to have accepted it. Shorter retention lowers storage and writes together rather than separating them.
  • Writes. Documents written per month at the selected row size. Write tokens follow the bytes written. The estimate assumes batched ingest of at least 1,000 documents per write; writes carrying fewer documents bill the 1 WT per-write minimum instead.
  • Queries. Monthly queries converted to average QPS over 730 hours. Capacity reflects sustained traffic.
  • Returned bytes. Result count multiplied by payload per result. Vector queries return identifiers and scores rather than the embeddings, so they are costed at 1 KB per result; the other query types use the selected row size.
  • Hybrid rows. Text and columns use the selected document size; one 1024-dimension fp32 vector adds 4 KB.

Infino

Infino bills four meters: storage, write tokens (WT), read tokens (RT), and returned bytes. Write tokens meter ingest and read tokens meter queries, each at its own rate. Returned bytes are a flat rate. Current rates appear in the calculator.

Write tokens follow the bytes written. A 1024-dimension fp32 embedding is 4 KB. Hybrid search + SQL writes the selected text or columns plus that vector. The estimate assumes batched ingest of at least 1,000 documents per write; writes carrying fewer documents bill the 1 WT per-write minimum instead.

Production billing meters the work each write actually performed.

Query compute varies widely with query shape, data shape, filter selectivity, result count, vector dimensions, and index layout. The read-token estimates below are rough averages measured against a reference corpus of approximately 1 million documents at typical row sizes, across a variety of queries per shape:

  • full-text mix: ~1.4 RT per query.
  • vector top-k: ~1 RT per query.
  • crosstab SQL: ~6.1 RT per query.
  • hybrid search + SQL: ~8.5 RT per query.

These calculator defaults are rough averages. A narrow filter on a well-cached corpus will consume fewer tokens; a broad scan over cold data will consume more. Production billing meters actual on-CPU query work. Usage below the account minimum is billed at that minimum; the current floor is in the calculator.

A query on a larger corpus touches more data, so the estimate grows read tokens per query with the corpus. These averages held from the reference corpus through 10 million documents, so the estimate holds them flat to that point and then adds half as much again for every subsequent 10× of documents. That growth rate is an assumption rather than a measurement. Query latency rises faster than that on larger corpora, but latency includes waiting on storage while read tokens meter on-CPU work, and the two separate once the working set stops fitting in cache.

Read tokens bill on demand. Pinned tables assumed at higher volumes. Heavier shapes reach that point at lower query-QPS because they use more RT per query. A pin provides 500 RT/s of capacity. Infino’s vector index is adaptive and moves away from HNSW as a corpus grows, so serving throughput at scale differs from a benchmark measured on HNSW, and this capacity is sized for the index that serves at scale to more closely track adaptive costs. Query QPS per pin is that capacity divided by RT per query (500 QPS vector, 82 QPS SQL, 59 QPS hybrid). Pin count is the ceiling of RT/s divided by 500. Infino manages serving capacity and cache placement; object storage remains durable while RAM and NVMe serve as caches.

What each query shape costs

The estimates above are averages across a shape. The tables below break that out per shape, so a workload with a known query mix can be costed directly: each row is measured query work run through the meter exactly as an invoice would, rounded up to whole read tokens with a 1 RT minimum per query.

  • Corpus. The same reference corpus of approximately 1 million documents, in steady state.
  • Range. 1 RT to 14,143 RT, four orders of magnitude, so the bars are logarithmic.
  • To estimate a bill. Multiply the RT for each shape by how often you run it, sum, and apply the RT rate in the calculator.

Vector search

Shape Billed RT Relative cost
Vector kNN, top-10 1

Full-text search

Cost tracks how selective the query is. Rare terms narrow to almost nothing; wide ORs and common-word phrases match across most of the corpus.

Shape Billed RT Relative cost
Single term matching one document 1
Single rare term 1
Two-term AND, small result set 1
Rare required term, common optional term 1
Common required term, common optional term 2
Two-term AND 2
Two-term OR 4
Single common term 8
Three-term AND, wide terms 10
Three-term OR, wide terms 13
Three-term AND, similar terms 18
Five-term AND 23
Two required terms, two optional 27
Two-word phrase, mixed frequency 30
Ten-term AND 31
Three-term OR, similar terms 40
Five-term OR 94
Phrase plus a required term 269
Ten-term OR 315
Two-word phrase, common words 627
Twenty-term OR 761
Three-word phrase, common words 834
Forty-term OR 1,521

Term count and term frequency compound: a forty-term OR costs roughly 1,500× a single rare term. Phrases over common words are the most expensive shape here, above any AND in the table.

SQL

What a SQL query costs depends less on how much data it names than on whether it can be answered from table metadata, and whether it has to return rows.

Shape Billed RT Relative cost
MAX / AVG / SUM WHERE key = ? metadata only 1
COUNT(*) metadata only 1
MAX over the text column metadata only 1
GROUP BY category metadata only 1
COUNT filtered by category metadata only 1
COUNT filtered by rating metadata only 1
AVG(rating) WHERE category = ? metadata only 1
exact_match index only 1
token_match, selective index only 1
COUNT(*) WHERE key = ? 1
COUNT + SUM over a text window metadata only 1
SUM(rating), matches every row metadata only 1
bm25_search 1
AVG(rating) GROUP BY category 3
COUNT(*) GROUP BY bucket, category 3
vector_search 1 called directly 9
WHERE key = ?, unsorted column point lookup 11
WHERE title = ?, sorted column point lookup 13
hybrid_search 19
token_match, all rows 310
WHERE rating < N, returns rows returns a large result set 14,143

An aggregate answered from metadata costs 1 RT even when it covers every row, as SUM(rating) across the whole table does. 9 of the shapes above bill the minimum for that reason and 2 more are answered from the index alone; the remaining 2 do enough work to read data and still land at the minimum.

Returning rows is the expense. WHERE rating < N names the same data and costs 14,143 RT, because it returns a large result set.

How to read these

  • One corpus, one scale. All three tables share a corpus, so they are comparable to each other. Absolute values scale with corpus size; the ordering is the durable part.
  • The same operation costs differently by API. A vector search is 1 RT called directly and 9 RT as a SQL table-valued function.

Full-text alternatives

Elastic Cloud Hosted

Two-zone Platinum deployment on AWS us-east-1, CPU-optimized ARM. Elastic’s production planning sizes one zone for the full search load and adds a second zone for high availability. Both floors are Elastic’s own published production minimums rather than our reading of what a search deployment needs: 4 GB RAM per Elasticsearch node, and 2 GB per Kibana instance (the default for deployments created since May 2026). Capacity grows above those floors with indexed storage, vector RAM, and query CPU. Below six data nodes, the hot nodes are master-eligible and Elastic adds an included 1 GB voting-only tiebreaker. At six data nodes, the estimate adds three dedicated 4 GB masters. Snapshots and data transfer are included when they exceed the free allowance.

Amazon OpenSearch Service

Production domain on AWS us-east-1 using Multi-AZ with Standby: three Availability Zones, data-node count a multiple of three, two replicas (three copies of the index). Two AZs serve search and one remains standby; query CPU is sized on the active pair while all three are billed. Data nodes start at r6g.2xlarge (8 vCPU / 64 GiB); r6g.large and r6g.xlarge are starter search SKUs. Dedicated masters follow AWS’s published table by data-node count (m6g.large only through 10 data nodes; larger domains use r6g.xlarge / r6g.2xlarge / r6g.4xlarge). AWS describes a two-copy domain as its older guidance and requires three copies for Multi-AZ with Standby, so this is the topology they document for production rather than a premium the estimate chose. Automated snapshot storage is free for 14 days, and only manual snapshots reach S3, so no snapshot charge is billed. The estimate adds gp3 storage and standard AWS internet egress.

Vector alternatives

Qdrant Cloud

Standard packages on AWS us-east-1, at least three nodes, replication factor two. Production sizing begins at 64 GB / 8 vCPU; gpx1 through core1 are treated as starter packages. The database nodes form the Raft voting quorum for cluster metadata, and Qdrant Cloud management is included in package pricing. RAM follows Qdrant’s documented large-collection path: scalar-int8 vectors and HNSW in memory, original fp32 vectors on disk for rescoring. That is their “original cold, quantized pinned” tier — the memory-saving one; their default keeps both copies in RAM and would price higher. Each factor in the sizing is Qdrant’s own: scalar quantization converts float32 to uint8 for a quarter of the memory, the HNSW graph and metadata add half the vector size again, capacity planning multiplies by the replication factor, and Qdrant asks for roughly 20% headroom on the final RAM and disk totals. Disk carries both the fp32 originals and the quantized copy beside them. Query CPU is 20.2 RT/s per vCPU, and only on clusters of at least 16 vCPU. In VectorDBBench on Cohere 10M × 768 — the corpus size this calculator anchors its query scaling at — QdrantCloud-16c64g serves 323.4 unfiltered queries per second on 16 vCPU at 0.9507 recall. Filtered runs are faster and are not used. Egress uses standard AWS internet-egress tiers (Qdrant Cloud on AWS us-east-1).

Pinecone

The estimate uses the cheaper valid path between Standard on-demand and Dedicated Read Nodes. On-demand queries use read units based on the targeted namespace size, and only while that path stays under Pinecone’s published 2,000 RU/s index limit. Dedicated capacity uses 250 GB shards at 75% target fullness and n+1 replicas. Per-replica throughput is the one per-replica figure Pinecone publishes — its replica-sizing example, where one replica handles 50 QPS at a target latency and replicas are required QPS divided by that — with t1 scaled from b1 by the ratio Pinecone documents between the two node types, about four times the compute at three times the cost. Pinecone’s headline 2.7k and 5.7k QPS results are not used as a replica rate: they describe a 1.4 billion-vector deployment, which at 250 GB per shard spans dozens of nodes, so they size a fleet rather than a machine. That working set is still the largest Dedicated Read Nodes example published, so the row ends there. Pinecone’s managed control plane is included; storage, writes, and egress remain usage-based.

Elastic Cloud Hosted

Vector mode uses the same two-zone Platinum topology as full-text: Elastic’s published 4 GB per-node and 2 GB Kibana minimums, dedicated masters at six data nodes, snapshots and data transfer over the free allowance. Vector RAM is added on top of indexed storage: each row contributes a quantized vector plus graph overhead, and both zones hold a copy. Query CPU uses the same 22 RT/s per vCPU density as full-text, and the row scales through high query volumes.

Amazon OpenSearch Service

Vector mode uses the same Multi-AZ with Standby topology as full-text: three AZs, two replicas, data nodes starting at r6g.2xlarge, dedicated masters from AWS’s table. Vector RAM is included in the serving-RAM calculation on the two active AZs. Query CPU uses the same 22 RT/s per vCPU density as full-text. gp3 storage, free automated snapshots, and standard AWS internet egress are unchanged.

Vector performance differences across vendors

One VectorDBBench run on Cohere 1M × 768, unfiltered, each vendor at its fastest configuration.

Engine queries / sec vs Infino Configuration
Zilliz Cloud 13,320 0.34× 8cu-perf
Milvus 10,660 0.43× 16c64g sq4u-fp16 force-merge
Infino 4,574 1.00× 16c64g · single node
OpenSearch 3,055 1.50× 16c128g force-merge
Elastic Cloud 2,808 1.63× 8c60g force-merge
Qdrant Cloud 1,242 3.68× 16c64g
Pinecone 1,147 3.99× p2.x8 1node
pgvector 10.63 430.29× 2c8g · 2023 run · 0.89 recall

Infino's result is a single node; competitors are free to scale horizontally. Zilliz Cloud is managed Milvus, so the two rows above Infino are one vendor's engine in two packagings, published by the vendor that maintains the benchmark. Infino's row is submitted and awaiting publication. Rows rank on throughput alone, so recall is not constant down the column; the densities below hold it at 0.95 or better, which sometimes names a different run of the same engine. Qdrant and Infino are the two rows our calculator serves from. Pinecone is not, because it has no unfiltered run that reaches 0.95 — its unfiltered results peak at 0.93 recall here, and every Pinecone run above 0.95 filters out 98% or more of the corpus first. It is sized from its own replica-sizing guidance instead. Elastic and OpenSearch use their full-text densities.

SQL alternatives

Amazon RDS PostgreSQL

Multi-AZ r6g instance plus gp3 and AWS egress. The primary/standby topology and RDS control plane are included in the Multi-AZ price. SQL mode stores columns only. Hybrid mode adds one fp32 vector per row and a resident pgvector HNSW index. When columns plus a 25% index allowance (and HNSW, in hybrid) fit on one RDS node, the instance is sized to keep that working set in RAM. Query CPU stays at 2 RT/s per vCPU in both modes. Hybrid includes the SQL work, so adding pgvector and full-text cannot raise throughput above the row-store SQL rate. Hybrid serving starts at r6g.2xlarge (8 vCPU): r6g.large and r6g.xlarge are starter search SKUs on this family, the same floor Amazon OpenSearch uses for data nodes. The Multi-AZ standby does not serve queries. The row ends when one standard PostgreSQL node can no longer satisfy RAM, vCPU, or storage.

ClickHouse Cloud

Managed Scale service with two replicas, logical storage plus one backup, and public-internet egress. ClickHouse Keeper and the managed control plane are included in the service price. BYOC is excluded because Keeper and supporting infrastructure create a separate cloud bill. Compute grows with stored TB, indexed writes, and query throughput. SQL replica RAM uses ClickHouse’s 1:50 memory-to-storage ratio for frequent access; the 8 GiB-per-TB pairing on the Scale price card is excluded.

Query CPU uses 32 RT/s per vCPU. On ClickBench at 100 million rows on a c6a.4xlarge, the 43-query suite runs in 18.4 s on ClickHouse against 34.0 s on Infino, so ClickHouse is 1.85× the Infino rate of 17.5. Below 1 QPS the service stays on the published HA starting configuration (2 replicas × 8 GiB / 2 vCPU, $437 always-on). At 1 QPS and above the floor is ClickHouse’s published 3-replica × 16 GiB / 4 vCPU example (12 vCPU, $1,311 compute). The 16-vCPU benchmark machine validates the density while light SQL retains the smaller production floor. Postgres SQL keeps its separate 2 RT/s-per-vCPU density, and the two warehouses keep their own, derived below. When query rate is zero, the published HA configuration is the floor.

Snowflake

These lines price the selected SQL or hybrid-retrieval workload on Snowflake. Infino can replace that read path while Snowflake continues to provide its BI, governance, and sharing ecosystem.

SQL compute uses the same estimator as ClickHouse with Snowflake’s own density: 13 RT/s per vCPU, storage vCPU from ClickHouse’s 1:50 frequent-access RAM ratio (4 vCPU per 8 GiB RAM), and the same floors: 4 vCPU below 1 QPS, 12 vCPU at 1 QPS and above. The estimate selects the smallest published Snowflake warehouse that satisfies the required vCPU; it never bills a fraction of X-Small. Growth past 6X-Large continues at the X-Small credit-per-vCPU rate with the same density and 1:50 ratio.

That density comes from CostBench, comparing hot-run vCPU-seconds per query against the ClickHouse configuration in the same 1-billion-row run: Snowflake 0.92× at X-Small, 1.20× at Large, so 1.05×. That ClickHouse configuration is a 177-vCPU cluster running 2.31× less efficiently per vCPU than the single ClickBench node the other densities use, so the ratio rescales to 2.43× and 32 ÷ 2.43 = 13. The average excludes the 4X-Large row, where every engine including ClickHouse loses per-vCPU efficiency on a cluster far larger than the table needs.

The warehouse is Standard On Demand on AWS us-east-1 ($2.00 per credit, Snowflake Service Consumption Table effective 18 August 2026), always-on while average QPS is above zero. When query rate is zero, compute is zero. Storage is On Demand Standard table storage at $23/TB-month on the SQL working set (columns / documents only). Returned bytes carry no egress charge: Snowflake’s published internet rate is $90/TB from AWS US East, but its documentation states that it does not apply egress charges when a client or driver retrieves query results, and result retrieval is absent from the list of transfers that do incur the fee. Cloud Services under the 10% adjustment and capacity discounts are excluded.

Hybrid mode keeps that SQL warehouse (6.1 RT, query 7) and adds Cortex Search for full-text and vectors: keyword plus one 1024-dimension embedding per row. Serving is 6.3 AI credits per GB-month of indexed data (source bytes plus embeddings) at $2.00 per AI Credit on global routing, always-on while QPS is above zero. Embedding generation and the extra materialized Cortex copy are excluded, as they are for the other engines.

Databricks

Same estimator as Snowflake and ClickHouse, at Databricks’ own density of 8 RT/s per vCPU, with 1:50 storage RAM and the same 4 vCPU / 12 vCPU floors. The estimate selects the smallest published Databricks SQL warehouse that satisfies the required vCPU; it never bills a fraction of 2X-Small. Growth past 4X-Large continues at the 2X-Small DBU-per-vCPU rate with the same density and 1:50 ratio.

Derived the same way as Snowflake’s, from the same run: Databricks SQL Serverless spends 1.67× that cluster’s vCPU-seconds per query at 2X-Small and 1.87× at Large, so 1.77×, which rescales to 4.09× on the single-node baseline: 32 ÷ 4.09 = 8. Both warehouses are measured in CostBench rather than ClickBench because ClickBench does not disable result caching for cloud warehouses.

Compute is SQL Serverless on AWS us-east-1 Premium at $0.70 per DBU (infrastructure included). Always-on while QPS is above zero; suspended when it is not. Storage is AWS S3 standard at $0.023/GB-month for the SQL working set. Egress uses standard AWS internet-egress tiers. Lakehouse Real-Time beta pricing ($0.55/DBU) and committed-use discounts are excluded.

Hybrid mode keeps the SQL warehouse and adds Databricks AI Search for full-text and vectors (keyword + 1024-dimension). Units use the published 768-dimension capacities (Standard 2 million vectors / 4 DBU/hour, Storage Optimized 64 million / 18.29 DBU/hour), scaled by 1024/768, and the cheaper SKU wins. AI Search serving uses its published $0.07-per-DBU rate on AWS us-east-1. Embedding and sync-pipeline compute are excluded.

SQL performance differences across vendors

The 43-query ClickBench suite at 100 million rows, hot runs, expressed as vCPU-seconds of work per query.

Engine vCPU-s / query vs ClickHouse Measured on
ClickHouse 6.8 1.00× ClickBench · c6a.4xlarge
DuckDB 9.8 1.43× ClickBench · c6a.4xlarge
Infino 12.7 1.85× ClickBench · c6a.4xlarge
Snowflake 16.6 2.43× CostBench · rescaled
DataFusion 17.0 2.48× ClickBench · c6a.4xlarge
Databricks 28.0 4.09× CostBench · rescaled

ClickHouse, DuckDB, Infino, and DataFusion ran the same c6a.4xlarge, so those four are directly comparable. Snowflake and Databricks are taken from CostBench instead, because ClickBench does not disable result caching for cloud warehouses — Databricks records the whole suite in 4.5 seconds there, against 711 seconds for the same suite at ten times the data in CostBench. Their CostBench ratios are 1.05× and 1.77×, measured against a 177-vCPU ClickHouse cluster that runs 2.31× less efficiently per vCPU than the single node; the rows above rescale onto the single-node baseline and divide CostBench’s billion rows by ten to reach 100 million. Snowflake’s own ClickBench entries bracket the rescaled figure, at 1.57× on X-Small and 12.9× on Large. The Databricks entries there show the cache and cannot corroborate its row.

Hybrid full stack

Each hybrid-with-SQL query invokes all three systems. Elastic receives text and metadata. ClickHouse receives the columns. Qdrant receives text and metadata plus one 1024-dimension fp32 vector, sized on Qdrant Cloud Standard packages. Monthly writes are delivered to all three copies. This estimate excludes engineering and operational labor for every vendor, so keeping three systems in step is priced as a managed sync service rather than as staff time; costing it at zero would give the assembled stack a free component the single-system rows do not get. Ingest is one Fivetran Standard connection per copy: same document-write volume on each connection, Standard pay-as-you-go list, no annual-contract discount. Monthly active rows equal documents written; Fivetran does not charge the initial load. Below 1 million MAR the published Standard rate is about $500 per million MAR ($5 connection minimum). Above that the estimate follows Fivetran’s published Standard examples at 2.7, 5.4, and 27 million MAR. The displayed full-stack total is the three hosted bills plus those three connections. Pinecone is compared only in vector mode; past its published Dedicated Read Nodes working set that row is omitted, so the hybrid stack uses Qdrant for the vector copy.

What the estimate excludes

  • Negotiated discounts, annual commitments, credits, taxes, and support contracts.
  • Traffic peaks above the monthly average and workload-specific p99 headroom.
  • Engineering and operational labor.
  • Embedding generation and model inference.
  • Schema-specific compression, filter selectivity, and custom index tuning.

Public sources