# Pricing and cost control

This page explains what drives your WarpSearch bill and which design choices make it smaller. It
has no prices on purpose, so it stays true when they change. Current rates are on the
[pricing page](/pricing).

## What you pay for

There are only two usage meters:

- **Indexed data.** The size of what you have indexed, per month. Every account gets a free
  allowance that never expires.
- **Queries.** The number of searches you run.

There are no nodes, shards or replicas to size, so there is nothing to pay for while you are not
using it. Premium support is optional and billed separately from usage.

Both meters follow decisions you make, which means you can steer them. The rest of this page is
about how.

## Keeping indexed data small

Indexed data is usually the larger lever, because it is paid for every month whether or not
anyone searches.

- **Index what you search, not everything you have.** Declare the fields you need on the
  collection instead of leaving `fields` empty. When it is empty, every string value in every
  document is searchable, and so is indexed. Fields used only for display can live in your own
  database and be joined back by `id`.
- **Trim large text before indexing.** Long bodies of boilerplate (navigation, footers, legal
  text, repeated signatures) add size and noise but no relevance. Strip them first.
- **Chunk with intent.** If you split documents for vector search, overlapping chunks multiply
  what is stored. Use the smallest overlap that still keeps meaning intact.
- **Use `keyword` for exact-match fields.** Identifiers, categories and tags need exact
  matching and filtering, not full-text analysis.
- **Delete what you no longer search.** Expire old documents and drop collections you have
  stopped using. Data you do not need is data you pay to keep.

## Keeping vector costs down

Vectors are the biggest contributor to index size for most hybrid workloads, and a few choices
make a large difference.

- **Use approximate vector search, not exact.** Exact search compares your query against every
  vector, so cost grows with the size of the index. Approximate search returns the nearest
  neighbors from a navigable structure, for a small, usually unnoticeable, drop in recall and a
  large drop in work per query. Unless you have measured a quality problem, you do not need
  exact search.
- **Prefer smaller embeddings when quality allows.** Vector size scales with the number of
  dimensions. If a lower-dimension model or a truncated embedding scores the same on your own
  test queries, take it.
- **Embed only the fields that carry meaning.** A title and summary often retrieve as well as
  the full body, at a fraction of the vectors.
- **Let keywords do the easy work.** Hybrid search lets keyword matching cover exact names,
  codes and phrases, so you do not need to push vector recall up to cover them.
- **Re-embed only what changed.** Updating a document that did not change its meaningful text
  should not trigger new embeddings.

## Keeping query volume down

- **Filter in the query.** Put restrictions such as tenant, language or date in a filter instead
  of fetching broad results and discarding most of them in your application.
- **Fetch fewer results.** Ask for the page you are going to show, not hundreds of hits.
- **Debounce search-as-you-type.** Send a query when typing pauses, not on every keystroke.
- **Cache repeated queries.** Popular queries and landing pages repeat. A short cache in front
  of WarpSearch absorbs them.
- **Batch background work.** Jobs that run many queries, such as deduplication or evaluation,
  are worth deduplicating and rate-limiting.
- **Treat agents like any other client.** An agent that loops on search can run up a surprising
  number of queries. Cap its retries and tool calls.

## Measure before you tune

Look at what your collections hold in the [management console](/management/) before changing
anything. Cutting indexed fields or trimming chunks is easy to try on a copy of a collection:
compare result quality on your real queries first, then keep the version that is smaller without
being worse.

## Predictable spend at scale

If you run steady, high volume, or have to keep data inside your own cloud account, ask about
bring-your-own-cloud deployments. [Contact us](/contact?topic=sales) and we will work through it
with you.