Managed vector search — free tier
Search for meaning, not for words
Vela indexes your embeddings and answers by similarity in milliseconds. One single API for semantic search, RAG and recommendation, up to a billion vectors.
- p99 latency
- 0 ms
- Target recall
- 0.2 %
- Maximum dimensions
- 0
- Deployment regions
- 0
A keyword index only finds what you already knew how to name. It ignores synonyms, rephrasings, other languages.
A vector index compares meanings. Same query, but it brings back what you were looking for.
What the engine does
A vector index, without the cluster
You stay in control of your models and your data. We take care of indexing, graph traversal and holding latency in line.
-
One single API
Create an index, send your vectors, query them. No infrastructure to size or operate.
-
Predictable latency
The p99 stays under 12 ms on a billion-vector index, including when a query carries a filter.
-
Metadata filters
Restrict a search to one customer, one language or one time window. The filter applies during graph traversal, not after.
-
Queryable writes
An inserted vector becomes searchable within seconds. No reindexing window to schedule.
-
Data residency
The region is chosen when you create the index, from eight options. Multi-region replication stays optional.
-
Your models, your vectors
Up to 4096 dimensions, cosine similarity or dot product. Vela imposes no embedding model.
Similarity search
Two neighbouring vectors, two neighbouring ideas
An embedding places a text, an image or a product in a space of several thousand dimensions. Two pieces of content about the same thing end up side by side in it.
Vela walks that space with an HNSW graph and returns the k nearest neighbours of a query, without ever comparing it to the other billion vectors.
Going to production
From the index to the first query
Four steps, in this order, to go from an empty index to answers in production.
- 01
Indexing
Create an index by setting its dimensions, its similarity measure and its storage region.
- 02
Ingestion
Send your vectors in batches, along with the metadata your filters will later rely on.
- 03
Query
Ask for the k nearest neighbours of a vector, with or without a filter, and get the scores back.
- 04
Operations
Track recall and latency in production, then tune the graph parameters if you need to.
Where we stand
Three deliberate trade-offs
A vector database is judged on what it gives up. Here is what we chose.
The p99 matters more than the average. An index that answers in 3 ms nine times out of ten, then in 400 ms on the tenth, is unusable behind a conversational assistant.
A highly selective filter collapses recall long before it hurts latency. We filter during graph traversal rather than after, so the neighbour list stays relevant.
A 1536-dimension vector takes roughly 6 KB in memory, graph included. Quantization cuts that cost, and a final reranking pass recovers the precision lost.
Engineering log
Latest articles
What we learn from running vector indexes in production.
- Why keyword search hits its limits What BM25 does well, what it cannot do, and why vector similarity search complements the lexical index rather than replacing it.
- Choosing your embedding dimension Memory cost per vector, how dimension affects recall, quantization and truncation: how to decide before indexing a large corpus.
- Reducing the p99 latency of a vector index Why the tail degrades before the median: efSearch, metadata filtering, reindexing, and how memory pressure shows up in high percentiles.
Your first index in five minutes
The Discovery tier is free: one index, one million vectors, no credit card. You move up a tier when your queries call for it, with no reindexing.