Vector & Time-Series Databases
Two more specialized storage models — similarity search over embeddings, and columnar storage for timestamped data.
Overview
Vector databases and time-series databases are two more specialized storage models, each optimized for a data shape general-purpose databases handle poorly — vector databases for high-dimensional embedding similarity search, time-series databases for timestamped, append-only metrics and logs.
Why It Exists
An AI application needs to find 'similar' items by comparing high-dimensional embedding vectors — an operation a relational index has no concept of at all, which is exactly what specialized approximate-nearest-neighbor indexes like HNSW and IVF exist to make fast. Separately, observability and IoT workloads generate a continuous, append-only stream of timestamped numeric data at huge volume, which a general-purpose row store handles far less efficiently than a columnar, time-partitioned engine built specifically for that access pattern.
Real World Example
A RAG (retrieval-augmented generation) AI application embeds a user's question into a vector and asks a vector database — pgvector, Qdrant, Pinecone — for the most similar stored document chunks via an HNSW index, running fast approximate search across millions of high-dimensional vectors. Separately, a monitoring platform ingests millions of timestamped CPU and memory metrics per minute into a time-series database like TimescaleDB or ClickHouse, which stores them column-by-column and compressed, specifically because time-series data is almost always queried by aggregating over a time range, not by fetching individual rows.
Example Data
Approximate nearest-neighbor search — the query vector's closest matches, with a similarity score
| Rank | Document Chunk | Similarity Score |
|---|---|---|
| 1 | doc_204, chunk 3 | 0.94 |
| 2 | doc_091, chunk 1 | 0.89 |
| 3 | doc_204, chunk 7 | 0.87 |
Two Specialized Models, Side by Side
Vector Databases — Similarity Search Over Embeddings
Store high-dimensional embedding vectors and answer 'which stored vectors are closest to this one' — the core operation behind semantic search and RAG applications, which a standard B+ Tree or inverted index has no way to answer at all.
HNSW — Fast, RAM-Heavy Approximate Search
Hierarchical Navigable Small World — a graph-based approximate nearest-neighbor index. Very fast and accurate, but it needs to mostly fit in RAM, which becomes a real capacity constraint at large scale.
IVF — Smaller Footprint, Lower Recall
Inverted File Index — a clustering-based approximate nearest-neighbor index with a noticeably smaller memory footprint than HNSW, at the cost of somewhat lower recall (it can miss some true nearest neighbors).
Time-Series Databases — Columnar Storage for Timestamped Data
Store data column-by-column and partitioned by time, rather than row-by-row. Since time-series queries almost always aggregate over a time range across one or a few metrics, this layout lets the engine read only the relevant columns and time range, and compress far more effectively than a row store could.
Diagram
Two different specialized paths for two very different data shapes
Vector DB path
embed query → HNSW/IVF index → approximate nearest neighbors
Time-series DB path
ingest metric → columnar, time-partitioned storage → range aggregation
Common Mistakes
Using exact nearest-neighbor search at production AI scale
Why: Exact search over millions of high-dimensional vectors is far too slow for real-time use. HNSW and IVF trade a small amount of recall for orders-of-magnitude faster search, which is the right trade for nearly all real applications.
Fix: Default to approximate search (HNSW or IVF) and only reach for exact search if the dataset is small or the use case genuinely can't tolerate any recall loss.
Storing high-volume time-series data in a row-oriented general-purpose database
Why: Row storage isn't optimized for the 'aggregate over a time range' access pattern that dominates time-series workloads, and doesn't compress repetitive numeric time-series data nearly as effectively as a columnar layout.
Fix: Move to a purpose-built time-series database once ingestion volume and query patterns actually justify it — not before, if a simpler store is still keeping up.
Assuming HNSW and IVF are interchangeable
Why: HNSW is faster and more accurate but memory-hungry, needing to mostly fit in RAM. IVF has a smaller footprint but somewhat lower recall — picking the wrong one for the dataset size and hardware budget causes real problems either way.
Fix: Choose based on actual data volume versus available RAM, and benchmark recall and latency against the real workload rather than assuming one is universally better.
Interview Questions
Why can't a normal relational database index be used for vector similarity search?
A B+ Tree index is built for exact-match and range lookups on ordered, structured values. Similarity search needs to find vectors that are geometrically close to a query vector in high-dimensional space, which has no natural sort order a B+ Tree can exploit — it requires a fundamentally different index structure like HNSW or IVF.
What's the trade-off between HNSW and IVF?
HNSW offers faster search and higher accuracy (recall), but its graph structure needs to mostly fit in RAM, which limits how much data it can handle economically. IVF has a smaller memory footprint, making it more scalable for larger datasets, but at the cost of somewhat lower recall — it's more likely to miss some true nearest neighbors.
Why does a time-series database store data column-by-column instead of row-by-row, and how does that specifically help the typical time-series query pattern?
Time-series queries almost always aggregate one or a few specific metrics over a time range, rather than fetching entire rows. Columnar storage lets the engine read only the columns actually needed for that query, skipping everything else — and because values within a single metric's column tend to be similar or smoothly changing, they compress far more effectively than a row that interleaves many different, less-correlated metrics together.
Production Best Practices
Do
✓Default to approximate nearest-neighbor search (HNSW or IVF) for production-scale vector similarity search.
✓Move to a purpose-built time-series database once ingestion volume and query patterns justify it.
✓Benchmark HNSW vs IVF recall and latency against the real dataset and hardware budget.
Don't
✗Don't use exact nearest-neighbor search at a scale where it can't keep up with real-time requirements.
✗Don't keep high-volume time-series data in a row-oriented general-purpose database indefinitely.
✗Don't assume HNSW and IVF are interchangeable without checking memory constraints.
Comparison
| Optimized For | Index/Storage Type | Typical Query | |
|---|---|---|---|
| Vector Database | High-dimensional similarity search | HNSW or IVF | 'Find the k most similar vectors' |
| Time-Series Database | Timestamped, append-only metrics | Columnar, time-partitioned | Aggregate a metric over a time range |