One engine, all data types
CrateDB stores time-series telemetry, JSON documents, metadata, and vector embeddings as first-class citizens — not bolt-on features, not a federated layer over separate stores.
No synchronization pipelines
Standard SQL with AI primitives
Works with your AI stack
Vector search finds results based on semantic similarity rather than exact matches, comparing vector embeddings that capture the meaning of data (e.g., text, documents, images, videos).
CrateDB supports vector embeddings natively and allows similarity queries (e.g. k-nearest neighbors), combined with filters, aggregations, and full-text or time-series data, all in SQL.
Full-text or keyword search (e.g. BM25) matches exact or approximate lexical similarity (words, phrases). Vector search matches semantic similarity (e.g. meaning, context, concepts, embeddings). CrateDB allows hybrid search, combining vector and full-text search in the same query.
Yes. CrateDB is built to scale: high ingestion rates, storage of structured + vector + unstructured data, and efficient querying even with large embedding volumes.
CrateDB’s value proposition is to unify these: instead of separate vector stores, search engines, and analytics/OLAP systems, you can do embeddings + filtering + aggregations + full-text + search in one system. This reduces latency, complexity, and operational overhead.
Examples include: semantic search over documents, recommendation systems (matching embeddings), anomaly detection in real time, combining text search + vector similarity (hybrid search), powering chatbots or AI features that need fast access to embeddings + metadata + analytics together.
RAG Pipelines, short for Retrieval Augmented Generation Pipelines, are a crucial component of generative AI, that combines the vast knowledge of large language models (LLMs) with the specific context of your private data.
A RAG Pipeline works by breaking down your data (text, PDFs, images, etc.) into smaller chunks, creating a unique "fingerprint" for each chunk called an embedding, and storing these embeddings in a database. When you ask a question, the system identifies the most relevant chunks based on your query and feeds this information to the LLM, ensuring accurate and context-aware answers. They operate through a streamlined process involving data preparation, data retrieval, and response generation.
- Phase 1: Data Preparation
During the data preparation phase, raw data such as text, audio, etc., is extracted and divided into smaller chunks. These chunks are then translated into embeddings and stored in a vector database. It is important to store the chunks and their metadata together with the embeddings in order to reference back to the actual source of information in the retrieval phase. - Phase 2: Data Retrieval
The retrieval phase is initiated by a user prompt or question. An embedding of this prompt is created and used to search for the most similar pieces of content in the vector database. The relevant data extracted from the source data is used as context, along with the original question, for the Large Language Model (LLM) to generate a response.
While this is a simplified representation of the process, the real-world implementation involves more intricate steps. Questions such as how to properly chunk and extract information from sources like PDF files or documentation and how to define and measure relevance for re-ranking results are part of broader considerations.