How Search is metered on one credit balance
Base Rate Summary: Index storage is 0.04 credits per GB-hour. Queries run inside your functions and workers at 0.01 credits per GiB-second; embeddings with text-embed-v1 cost 3 credits per 1,000 tokens. Egress is 9.00 credits per GiB.
The three places search spends credits
Storage first: an index over a 10 GB corpus costs in the neighbourhood of 292 credits a month, scaling with corpus size at the storage rate. Embedding second: building or refreshing vectors costs tokens — a million-token corpus is 3,000 credits, paid on change, not per query. Querying third: each search is function execution, fractions of a GiB-second for an index lookup and a keyed read of the winning records.
What disappears from the old bill
No cluster nodes burning around the clock, no per-unit search pricing, and no sync pipeline tax — because the index is declared over the source tables and buckets, keeping it fresh is not a job you staff. What remains genuinely priced is the physics: storing vectors and reading them. Teams crossing over usually discover their “search bill” was mostly an idle cluster waiting for queries.
- Text and vector indexes over the same corpus share the storage rate — hybrid search is not two products
- Re-embedding after a model change is a token spend you can compute in advance from corpus size
- Zero-result and click logs are your tables, so search quality work reads product data, not a vendor dashboard
Credit Consumption Scenarios vs Hyperscaler Billing
| Workload Scenario | Monthly Resource Footprint | KERNSTACK Credits | Hyperscaler / SaaS Equivalent |
|---|---|---|---|
| Light | Docs/FAQ corpus: 2 GB indexed, 20k queries/month | ≈60 credits storage + a few hundred for queries | Smallest managed search cluster bills hourly all month, sized for peaks that arrive twice a year |
| Steady | Catalogue search: 50 GB corpus, 2M queries/month, monthly re-embeds | ≈1,460 storage + ≈200 query compute + embed spend | Cluster nodes plus per-request pricing, and a separate vector product if semantic ranking joins later |
| Heavy | Large archive: 500 GB indexed, 20M queries/month | ≈14,600 storage + query compute at volume | Multi-node cluster with replication; egress to your app tier billed per GiB on top |
Frequently asked questions
The embedding of the corpus — tokens at 3 credits per 1,000 with text-embed-v1 — plus the vector index’s storage at the same rate. The two indexes can be declared over the same sources; hybrid ranking is then a function-level decision.
Right. A query spends its function’s GiB-seconds. An index lookup and a handful of keyed reads is a small fraction of a second, so millions of queries land in the low hundreds of credits of compute.
When search is the product at serious scale: relevance teams, extreme query volumes, specialised ranking pipelines. Product-scale corpora pay the cluster tax for capacity they never use — that is the segment this pricing is built for.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.