Infino
talk to an engineer sign up

Pricing methodology

Updated August 2026 · 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 may cost roughly the same across systems. Infino’s larger savings 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. Columnar SQL (ClickHouse, Snowflake, and Databricks) uses the same ClickBench GROUP BY density (48 RT/s per vCPU). 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 so the same vCPU need can pick a published credit or DBU SKU. Serial CostBench latency is excluded from the throughput density.

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. It cannot be lower than documents written during that month.
  • Writes. Documents written per month at the selected row size. Write tokens follow the bytes written.
  • Queries. Monthly queries converted to average QPS over 730 hours. Capacity reflects sustained traffic.
  • Returned bytes. Result count multiplied by the selected row size per result.
  • 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. A write token is the same unit of work as a read token. 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.

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.

Read tokens bill on demand. Pinned tables assumed at higher volumes (one pin is priced as 9 QPS of 1.0 RT vector work). Heavier shapes reach that point at lower query-QPS because they use more RT per query. A pin provides 500 RT/s of capacity. 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
Vector kNN, 1.000 guaranteed recall 2,007

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. Thirteen of the shapes above cost 1 RT for the same reason.

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. The published 4 GB minimum supports monitoring and ILM; this estimate starts search capacity at 8 GB RAM per zone, then grows with indexed storage, vector RAM, and query CPU. Kibana is 2 GB per zone (Elastic’s production minimum, and the default since May 2026). 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). The estimate adds gp3 storage, snapshots, 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. Query CPU is 10 RT/s per vCPU from Qdrant’s public 21M-vector two-stage benchmark on 3 × 4-vCPU, and only on clusters of at least 12 vCPU. 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, n+1 replicas, the published b1 50 QPS example, and Pinecone’s published 2.7k QPS unfiltered result on 1.4 billion vectors as the t1 replica anchor. That 1.4 billion-vector working set is the largest published Dedicated Read Nodes example, 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: 8 GB RAM per zone as the search floor, 2 GB Kibana per zone, 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 vector density of 32 RT/s per vCPU, 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 vector density (32 RT/s per vCPU). gp3, snapshots, and standard AWS internet egress are unchanged.

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 48 RT/s per vCPU from ClickBench query 7 (columnar GROUP BY), measured on 16 vCPU. 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). Growth past 12 vCPU still uses query 7. 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. 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: query vCPU from the ClickHouse GROUP BY density (48 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.

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). Internet egress uses the published $90/TB AWS US East rate. 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: the ClickHouse GROUP BY density, 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.

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.

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. 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