VectorDB overview
This page explains what a vector database is, how VectorDB works on the Crusoe AI Platform, and when you should reach for it. No prior machine-learning knowledge needed.
What vector search is, in plain words
Normal search matches words. If you search a database of support tickets for "refund", you find tickets that contain the word "refund" — and miss the one that says "I want my money back".
Vector search matches meaning. It works in two steps:
- Turn text (or images, or audio) into a list of numbers. An AI model called an embedding model reads your content and outputs a fixed-length list of numbers — for example, 1,536 of them. That list is called an embedding or a vector. The model is trained so that content with similar meaning gets numbers that are close together. "I want my money back" and "please refund me" end up as nearly identical vectors, even though they share no words.
- Find the nearest neighbors. When someone searches, you embed their query the same way, then ask the database: "which stored vectors are closest to this one?" Closest vectors = most similar meaning.
A vector database is a database built to store millions of these vectors and answer that "which are closest?" question fast. VectorDB is the Crusoe AI Platform's managed vector database.
VectorDB stores and searches embeddings — it does not generate them. You run your content through an embedding model (any provider works), then write the resulting vectors into VectorDB. Every vector in one index must come from the same model, so the numbers are comparable.
The platform hosts an embedding model for you — qwen-embedding, served at POST /v1/embeddings (see Inference). Create an index without naming a width and you get exactly the width that model produces, so embedding with our endpoint and writing the result works with nothing set. Name a width only when your vectors come from a different model.
The 30-second mental model
- You create an index: a named container for vectors. Every vector in it has the same width — the same number of dimensions — and is compared using the same distance rule.
- You write points into it. A point is one vector, plus an optional JSON payload (metadata such as
{"tag": "alpha"}), plus an optional id. - You query with a vector. Back come the top-k nearest points — the k closest ones, where you pick k — each with a similarity score. You can also filter results by payload.
VectorDB runs on shared platform capacity, and the index is the only thing you name. Internally each index gets a storage name built from your project plus the name you chose, which is why two projects can both own an index called documents without colliding. Every index is scoped to your project and invisible to every other project.
When to use it
Use VectorDB when the question is "what is similar to this?":
- Semantic search — search docs, tickets, or products by meaning, not keywords.
- RAG (retrieval-augmented generation) — fetch the most relevant snippets from your own data and hand them to a language model so its answers are grounded in facts.
- Agent long-term memory — the platform's agent memory bank is built on VectorDB.
- Recommendations and deduplication — "users who liked this", "have we seen this before?".
Do not use it as a general-purpose database. It cannot join two sets of records together. It has no transactions — groups of writes that either all succeed or all roll back. Payload filtering narrows a similarity search; it is not a full query language. For plain key-value data, use MemoryStore.
How it compares
AWS and Azure fold vector search into a general search engine. GCP has a dedicated product but recently rewrote its data model. VectorDB is a dedicated vector database and nothing else.
| Crusoe VectorDB | Vertex AI Vector Search (GCP) | OpenSearch vector engine (AWS) | Azure AI Search vectors | |
|---|---|---|---|---|
| What it is | Dedicated vector database, and nothing else | Dedicated vector product (ScaNN-based) | Vector fields inside a search/analytics engine | Vector index type inside a search service |
| Ready to query | Immediately after the index reports ready — no separate "deploy to endpoint" step | Requires deploying an index to an endpoint (1.0 model) or the newer Collections model | After index mapping setup | After index + vectorizer/profile setup |
| Result count control | One parameter: top_k | neighbor_count | Two parameters (k and size) that must agree | k per vector query |
| Capacity planning | None — shared platform capacity | Node-hours per deployed replica, billed while idle | OCUs / instance sizing | Search Units = replicas × partitions |
| What they have that we don't (yet) | — | Global regions, SLAs, hybrid search, autoscaling at huge scale | Full-text + hybrid search, aggregations, mature IAM | Hybrid + semantic ranking, multi-language SDKs |
Key Architecture Specifications: VectorDB is designed for high-performance dense vector search. Each point holds a vector alongside arbitrary JSON payload metadata. Indexes are isolated per project, providing high-throughput similarity search and payload filtering.
In this section
- Quickstart — create an index, insert points, and search in about five minutes.
- Indexes and points — the full data model: dimensions, distance metrics, payloads, ids, and what can and cannot change.
- Search — query patterns: top-k, filters, scores, browsing, and deleting points.
- Use with agents — how the agent memory bank relates to VectorDB.
- API reference — every endpoint, field, and error.
- Troubleshooting — real error messages and fixes.
Related: Inference — the platform's hosted embedding and reranking models.