Design a Vector Database

A managed vector database: 10,000 tenants, 20 B vectors, filtered top-k in under 50 ms at 0.95 recall, and writes searchable in seconds.

Last updated 2026-10-27. Difficulty: hard. Patterns: vector-search, ann-indexes, quantisation, segments, multi-tenancy. Reported at OpenAI, Anthropic, Databricks, Snowflake, Google, Meta.

Functional requirements

• Create an index. Name, dimension (768 or 1536 here), distance metric (cosine, dot product or Euclidean), the metadata fields to make filterable, an optional embedding-model tag, and a performance or cost class. Dimension and metric are fixed for the index’s life.
• Upsert vectors with metadata. Batches of up to 1,000 of { id, values, metadata }; an upsert of an existing id replaces it. The response carries a log position the client can pass back for read-your-writes.
• Delete. By id, by filter, or a whole namespace. A deleted vector must stop matching within seconds and be physically gone within a bounded time, because customers delete for legal reasons.
• Top-k query with metadata filters. A query vector, k up to 1,000, and a filter such as category = shoes and price < 100: equality, set membership and numeric ranges combined with and/or. High recall even when the filter allows 0.1 % of the index.
• Namespaces. Partitions inside an index by a key every query carries, such as an end user or a project, so a query only touches that slice. The cheapest filter there is, and the one customers should use for high-cardinality keys.
• Bulk import. Load hundreds of millions of vectors from Parquet files in the customer’s bucket without going through the upsert API, for first loads and for re-embedding with a new model.
• Aliases. A stable name that points at an index and switches atomically, so a tenant can move to an index built with a new embedding model without its clients ever querying a half-built one.
• Out of scope. Producing embeddings (customers bring vectors; the RAG System question designs the pipeline that does), keyword and hybrid BM25 search, cross-region replication, and billing.

Non-functional requirements

• Scale and skew (10 k tenants · ~20 B vectors). From a few thousand vectors to 2 B in one index, at 768 or 1536 dimensions. About a hundred tenants send most of the queries and most of the rest are idle most of the hour, so one layout has to suit both ends.
• Latency at a recall target (p99 < 50 ms · recall@10 ≥ 0.95). The requirement behind the hardest trade-off. Recall, latency and memory cannot all be maximised, so the index type, the quantisation and where the bytes live are chosen to hit both numbers at the lowest cost, and recall is measured continuously rather than assumed.
• Throughput (50 k queries/s · 100 k upserts/s). At peak, fleet-wide. One index takes 5 k queries a second on its own; upserts arrive in batches and include bulk loads and re-embeddings.
• Freshness (searchable p99 < 2 s). From the acknowledged upsert to appearing in results, and the same for a deleted vector disappearing. Building a graph index takes minutes, so freshness cannot wait for one.
• Durability (0 acknowledged writes lost). An upsert is acknowledged once two of three zone replicas of the log have it, and it reaches object storage within seconds. Every query node can be lost without losing a vector.
• Availability (99.95 % for queries). A dead node or zone costs capacity, not answers: hot shards have replicas in two zones, and a shard that still misses its deadline is left out with the response marked partial.
• Cost (idle index ≈ storage only). An idle index should cost cents per million vectors a month, not dollars. That rules out keeping every index in RAM and makes object storage the source of truth.
• Tenant isolation (no cross-tenant reads). A query can only open its own namespace’s segments, enforced by routing rather than by a filter, and one tenant’s burst cannot push the others past their p99.

Back-of-envelope estimates

• Bytes per 768-d vector: 3 KB raw · ~900 B int8 + graph · 96 B PQ. float32: 768 × 4 = 3,072 B. Scalar int8: 768 B (4×). Product quantisation into 96 one-byte codes, or one bit per dimension: 96 B (32×). HNSW with M = 16 keeps 32 neighbours at the bottom layer, 32 × 4 B = 128 B, plus a few percent for the upper layers. The default hot form, int8 vectors plus the graph, is ~900 B; 1536-d vectors double every figure but the graph.
• The largest index: ~12 TB raw · 3.4 TB of RAM as int8 HNSW · 0.4 TB as an SSD graph. 2 B × 1536 × 4 B = 12.3 TB of float32, so a single exact query would read 12 TB. As int8 + HNSW: 2 B × (1,536 + 128 + ~50 B of ids) ≈ 3.4 TB of RAM per copy, seven 512 GB machines. As a graph on SSD: 192-byte PQ codes in RAM, ~0.4 TB, and full vectors with 64-neighbour lists on NVMe, 2 B × 6.4 KB ≈ 13 TB. At ~100 M vectors a shard, 20 shards.
• The whole fleet: ~80 TB raw · ~170 TB of RAM if kept naively. 20 B vectors at an average 1,024 dimensions (two-thirds 768, one-third 1536) × 4 B = 4 KB each, 80 TB. Held as float32 HNSW in RAM with two copies: ~4.2 KB × 20 B × 2 ≈ 170 TB, ~$850 k a month at an assumed $5 per GB-month. This is the number the design exists to avoid.
• Cost per million 768-d vectors a month: ~$16 float32 RAM · ~$5.5 int8 RAM · ~$1.5 SSD graph · ~9 ¢ idle. At assumed prices of $5 per GB-month for RAM, $0.25 for NVMe and $0.02 for object storage, one copy. float32 + HNSW: 3.2 GB of RAM, ~$16. int8 + HNSW: ~0.95 GB of RAM ($4.75) plus 3 GB of float32 on NVMe for re-scoring ($0.75), ~$5.5. Graph on SSD: ~0.15 GB of RAM ($0.75) plus ~3.3 GB of NVMe ($0.8), ~$1.5. Object storage alone, every file included (~4.3 GB), ~9 ¢: about 60× less than the hot int8 form. Idle indexes belong there.
• Query CPU at peak: ~145 k shard searches/s · ~435 cores busy. Of 50 k queries/s, 5 k go to the 20-shard index (100 k shard searches) and 45 k to single-shard indexes: 145 k/s. A shard search covers 10 to 15 segments, graph walks of a few tenths of a millisecond on the big ones and exact scans of the small ones, ~3 ms of CPU in all: 145 k × 3 ms ≈ 435 cores busy, ~1,100 provisioned at 40 % for headroom and hedges. The hot RAM tier needs ~10 TB for two copies, ~20 machines of 512 GB, so memory, not CPU, sets its size.
• Write path: ~440 MB/s into the log at peak. 100 k upserts/s × (4 KB of float32 at 1,024 dimensions + ~300 B of id and metadata) ≈ 440 MB/s, ×3 zone replicas ≈ 1.3 GB/s of log writes. At an average ~30 k/s that is ~11 TB of log a day, kept 24 hours. Appends are sequential and spread over hundreds of partitions: writes are a log-sizing problem, not an index problem.
• Index build compute: ~300 cores at peak. An HNSW insert at ef_construction 200 is ~5,000 distance computations, ~1 ms of one core at 768 d. Compaction rebuilds graphs at size tiers of ~100 k, ~1 M and ~10 M vectors, so each vector is indexed ~3 times: 100 k/s × 3 × 1 ms = 300 cores at peak, ~90 on average, on stateless builders that can run on spot capacity. A 10 M-vector segment is ~10,000 core-seconds, ~3 minutes on 64 cores. Building is cheap next to holding vectors in RAM.
• An idle tenant: ~1.7 ¢ a month · first query ~0.5 s. 200 k vectors at 768 d × ~4.3 KB in object storage (float32, int8, graph, metadata) ≈ 0.86 GB × $0.02 per GB-month ≈ 1.7 ¢. Waking it fetches ~200 MB of int8 vectors, graph and bitmaps with parallel ranged GETs at ~1 GB/s, ~0.2 s, so the first query takes ~0.5 s and the next ~10 ms. Kept hot, the same tenant would cost ~$1 a month of RAM per copy.

Components

• Customer app (RAG · search · recommendations): The tenant’s own service: a RAG pipeline (the RAG System question is one such customer), a product search or a recommender. It embeds documents and queries with its own model, upserts in batches with metadata and queries by vector with filters. It must embed queries with the same model as the index it searches, which nothing in the numbers can check.
• Embedding model (the customer’s · v1 → v2): Whatever model the tenant uses, hosted or its own, outside our system. It fixes the dimension and the space: vectors from two models are not comparable, so changing models means building a new index. We never see the text, only the vectors.
• API gateway (API key · quotas · aliases): Authenticates the API key to a tenant, resolves index names and aliases from the catalog, validates dimensions and the declared model tag, and charges per-tenant token buckets for queries and upserts before any work is done. Sends writes to the write service, queries to the coordinator, and imports to the control plane.
• Write service (stateless · hash(id) → shard): Splits each batch by hash of the id into the index’s 256 virtual buckets, maps buckets to shards and appends each part to that shard’s log partition, returning the highest log position. Routing by id means all writes for one id are ordered by one log. It never touches an index, which is why writes scale with the log.
• Write-ahead log (partition per shard · 3 zones): A replicated log of the Kafka or BookKeeper class, one partition per shard, acknowledged at two of three zone replicas in ~5 ms. It is the durable copy of every write until builders have sealed it into object storage, and the stream every query replica tails for freshness. Kept 24 hours; recovery replays from the offset recorded in the shard’s manifest.
• Query coordinator (fan-out · merge · hedge): Resolves (tenant, index, namespace) to shards and replicas from a cached catalog version and sends the query to one replica of each shard, choosing by fewest requests in flight. Hedges a shard that is slower than its own p95, merges the shards’ top k, and marks the answer partial if a shard misses the deadline. Logs a sample of queries, with the manifest versions they read, for the recall audit.
• Query nodes (segments · filters · re-score): Each hosts replicas of many shards: per shard, a growing segment per namespace built by tailing the log, the sealed segments of the current manifest, and their deletion bitmaps. A search turns the filter into a bitmap per segment, picks an exact scan or a filtered graph walk from the allowed count, re-scores candidates on full vectors and returns the shard’s top k. Nothing on a node is the only copy of anything.
• Segment cache (RAM · local NVMe · LRU by index): The query nodes’ memory hierarchy over object storage. RAM holds the int8 vectors, HNSW graphs, PQ codes and bitmaps of indexes queried in the last ~30 minutes (~5 TB per copy fleet-wide); NVMe holds float32 vectors for re-scoring, graphs on SSD and recently used segments; misses are parallel ranged GETs. Eviction is per index, by recency weighted by query rate, with a pinned tier for customers who pay never to be cold.
• Object storage (S3 class · immutable segments): The source of truth for everything sealed. Per segment: float32 and int8 vectors, metadata columns and their bitmaps, the sorted id table and Bloom filter, the graph or PQ files, and the deletion bitmap; per shard, every manifest version. ~110 TB for 20 B vectors, ~$2 k a month. Files are written once and never modified, which is what lets any node load them and any audit reproduce a query.
• Catalog (strongly consistent · etcd class): Small and strongly consistent: tenants and API keys; indexes with dimension, metric, model tag, filterable fields and class; aliases; the bucket-to-shard map; each shard’s current manifest version; replica placements and node leases. Every change is a compare-and-set on a version, so an alias switch or a manifest swap is one atomic step that every coordinator and node sees in the same order.
• Index builders (seal · compact · import): Stateless workers. They consume log partitions and cut the same offset ranges into sealed segments; run compactions that merge segments by size tier, drop deleted rows and build a fresh HNSW or SSD graph (~1 ms of a core per vector); and build segments straight from Parquet for bulk imports. Every new segment is checked with self-queries against an exact answer before it is offered for commit, and output goes to new object keys, so a crashed job leaves nothing visible.
• Control plane (placement · manifests · scaling): Decides where everything runs: shard replicas onto query nodes by RAM, NVMe and load; eviction of idle indexes and their warm-up; replica counts from query rates; tenant moves from pooled to dedicated shards; shard splits. Plans compactions per shard, hands them to builders, and commits each result as a new manifest version by compare-and-set, so it is the only writer of manifests.
• Recall auditor (batched exact search): Recomputes the exact answers of sampled queries on the very segments they searched, in one batched scan per index, and reports recall@10 per index, per plan and per filter-selectivity bucket. Its numbers drive the controller’s ef_search and scan thresholds and are shown to customers, because a quiet drop in recall is invisible from the outside.

User flows

1. Upsert a batch, searchable in a second. The write path runs on three clocks. An upsert is durable when two zones have it in the log (~5 ms), searchable when the query replicas have tailed it into a growing segment (well under a second), and cheap to search once a builder has sealed and indexed it (minutes). None of them waits for a graph.
   1. The client embeds 500 product descriptions with its model and upserts them with metadata. We never embed: the model is the customer’s choice and the database only sees numbers, so it never holds the text either. Batching matters: one request of 500 vectors costs one auth check, one quota decision and one log append per shard instead of 500. Values travel as packed float32 (gRPC, or base64 in JSON), about 2.5× smaller than JSON numbers.
   2. The gateway resolves the key, the index and its dimension from the catalog, and charges the tenant’s upsert quota. A 1536-d vector sent to a 768-d index, or one containing a NaN, is rejected here with a 400: it would break nothing visibly and quietly ruin recall. The catalog answer is cached for ~30 s with its version. The quota is a token bucket per tenant in vectors per second, so one tenant’s bulk load cannot crowd out everyone else’s writes.
   3. The write service splits the batch by hash of the id and appends each part to its shard’s log partition. Routing by id hash puts every write for one id in one partition, so an upsert followed by a delete of the same id is applied in that order by every replica. The append is acknowledged when two of three zone replicas have it, ~5 ms. No index is on this path, which is why 100 k upserts a second is a 440 MB/s log rather than 100 k graph inserts.
   4. Every query replica of the shard tails the partition and appends the vectors to the namespace’s growing segment. A growing segment is an array of float32 vectors plus metadata columns, searched by exact scan, so an insert is an append measured in microseconds. If the id already exists in an older segment, that row’s bit is set in its segment’s deletion bitmap in the same step, so the old and new copies never both match. Replicas apply the same log in the same order and converge without talking to each other; the vector is searchable ~200 ms after the ack.
   5. A query that carries the returned LSN is answered only by replicas that have applied it. Most queries do not need this: the promise is searchable within 2 s at p99. A client that writes and immediately reads its own write passes min_lsn, and the coordinator picks a replica at or past it, or waits up to a second for one. It is a consistency token, the same idea as a session token for read-your-writes in a replicated database.
   6. At 10 k vectors or 5 s, a builder seals the same log range into a segment in object storage. Builders consume the log independently of the query nodes and cut segments at offsets, so a segment is defined by its range, [88113000, 88123000), and every replica agrees on exactly what it holds. A small sealed segment is float32 and int8 vectors, metadata columns with bitmaps, a sorted id table and a Bloom filter: ~40 MB at 768 d, small enough to scan, so it gets no graph yet.
   7. The control plane commits a new manifest; replicas load the segment and drop those records from their growing segment. The manifest, the segment list plus the log offset it covers, is the unit of consistency: a query reads one manifest version plus the growing records past its checkpoint, so a vector is never counted twice or missed in the handover. The swap is a compare-and-set on the shard’s manifest version; if a compaction committed first, the controller rebases onto the newer version and retries.
   8. Later, compaction merges small segments into a larger one and builds its graph off the query path. Merging ten 100 k-vector segments into a 1 M-vector HNSW is ~1 ms of one core per vector, about half a minute on a 32-core builder, and it drops the rows marked deleted. Building fresh from immutable inputs is simpler and more predictable than patching a graph that queries are walking; each vector is rebuilt about three times in its life, at ~100 k, ~1 M and ~10 M.
2. Filtered top-k on one shard. The read path for a typical index: one shard, a dozen segments, and a filter that allows 3 % of the rows. Each segment picks its own plan from an exact count of allowed rows, and int8 candidates are re-scored on full vectors before the top 10 leave the node.
   1. The client embeds the query with the same model and asks for the 10 nearest shoes under 100. Same model is the one rule the database cannot check from the numbers: a query from another model is a valid vector whose neighbours mean nothing, and nothing errors. So an index can carry a model tag and a query that declares a different one is rejected. Filters use a small JSON grammar that compiles to bitmap operations, never arbitrary code.
   2. The coordinator maps the index to its shard and picks the replica with the fewest requests in flight. This index has 12 M vectors, so it is one shard with replicas in two zones. Picking by outstanding requests steers around a node that is momentarily slow without any global view. The shard map is cached with its catalog version, and a node that sees a stale manifest version in a request tells the coordinator to refresh.
   3. On the query node, each segment turns the filter into a bitmap of allowed rows, minus the deleted ones. Each segment keeps a compressed bitmap per value of every filterable keyword field and quantile buckets for numeric ones, so “shoes and price < 100” is a few bitmap ANDs and an AND NOT with the deletion bitmap, microseconds per segment. The popcount is an exact allowed count per segment, so the planner never has to guess selectivity.
   4. Each segment picks a plan: an exact scan when few rows pass, a filtered graph walk when many do. Here the 9 M-vector segment allows 270 k rows (3 %), so it walks its HNSW admitting only allowed nodes to the results, with ef raised to ~300; the small recent segments allow a few hundred rows each and are scanned exactly. Post-filtering is not a plan at this selectivity: an unfiltered top 40 would keep one or two shoes under 100.
   5. The node re-scores its best 40 candidates on float32 vectors from NVMe and returns its exact top 10 with metadata. int8 distances blur near ties, so the best 40 by approximate distance across all segments are recomputed on full vectors: 40 random 3 KB reads, tens of microseconds on NVMe. That wins back nearly all of the recall quantisation cost. The winners’ metadata is read from the segment columns here, so the coordinator needs no second round trip.
   6. The coordinator returns the merged top 10, and a sampled query is logged for the recall audit. ~8 ms at p50 for this shape: ~1 ms of auth and routing, ~4 ms of segment searches in parallel, ~1 ms of re-scoring, the rest network. Up to ~500 queries per index a day are logged with the manifest version they read and each segment’s results, so the auditor can recompute the exact answer later on the very same immutable files.
3. The 2 B-vector index at peak. The scale case: one index of 2 B vectors at 1536 dimensions taking 5 k queries a second. It is 20 shards of graphs on SSD, every query asks all 20 and waits for the slowest, so the tail and the replica count are the design problem, not the search itself.
   1. The coordinator sends the query to one replica of each of the 20 shards in parallel. Shards are by hash of the id over 256 virtual buckets, so every shard holds a uniform 5 % of the index and none is hot, but any of them may hold the best match, so all must be asked. Each returns its own exact top 10, and the union of those contains the global top 10, so 200 candidates are enough.
   2. Each shard walks a graph stored on NVMe, steering with compressed codes held in RAM. Per 100 M-vector shard: ~19 GB of 192-byte PQ codes in RAM and ~640 GB of graph nodes on NVMe, each node one record holding its full 6 KB vector and 64 neighbour ids. The walk keeps 4 reads in flight for ~25 rounds, ~100 reads and ~3–5 ms; because every read brings a full vector, exact re-scoring costs no extra I/O. This is the design DiskANN (Subramanya et al., NeurIPS 2019) introduced.
   3. Shard 7’s node is busy filling its cache, so after that shard’s p95 the coordinator hedges to the other replica. A query is as slow as its slowest shard: if each shard is slow 1 % of the time, 1 − 0.99^20 ≈ 18 % of queries meet at least one. Re-sending a straggler to its other replica after ~8 ms costs ~5 % more shard requests and means a slow query now needs two slow replicas at once. The losing call is cancelled.
   4. The coordinator merges 200 candidates and answers; a shard that missed the deadline is left out and flagged. p99 lands around 20 ms with hedging, inside the 50 ms budget. If a shard misses the 30 ms deadline even after the hedge, the answer comes from the other 19 with partial: true; on average it loses 5 % of the true top 10 for that one query, which beats failing it. A rising partial rate pages someone.
   5. Traffic rises 4× for an hour, and the control plane adds replicas that fill from object storage. Replicas exist for throughput and zone failures, not durability, so adding one is a cache fill and never a copy from a busy peer: ~660 GB per shard at ~2 GB/s, about 6 minutes. Until they are ready, the gateway holds the tenant to its provisioned rate with 429s, so other tenants do not pay for its spike. Predictable daily peaks get their replicas ahead of time.
4. A query node dies at peak. Query nodes hold nothing that is not also in the log and object storage, so a dead node costs capacity, never data. What matters is the minute between the crash and its replacement being warm and caught up.
   1. Node qn-31 stops renewing its lease, and after 10 s the control plane removes it from every replica list. Each node holds a lease in the catalog; on expiry the controller removes it from all of its shards’ replica lists in one versioned update, so coordinators stop choosing it within one refresh. Ten seconds trades detection time against evicting a node for a long garbage-collection pause.
   2. Queries in flight to qn-31 time out at the shard deadline and are retried on the other replica. Hedging already sends stragglers to the other replica after the shard’s p95, so during those 10 s, queries touching qn-31’s shards are a few milliseconds slower, not failed. Every hot shard has replicas in two zones, and nodes run at ≤ 50 % CPU so a survivor can carry its partner’s load.
   3. The control plane assigns qn-31’s shards to healthy nodes, which fetch the segments from object storage. A 50 M-vector RAM shard is ~48 GB of int8 vectors, graphs and bitmaps; parallel ranged GETs at ~2 GB/s load it in ~25 s, and the float32 vectors stream to NVMe afterwards, so for a minute that shard re-scores from int8 alone, a small recall cost. No surviving replica is asked for data, so recovery never loads a node that is already carrying extra traffic.
   4. Each new replica replays the log from its manifest’s checkpoint to rebuild growing segments and deletions. The manifest says which log offset its segments cover, so replay is seconds of records, not history. Deletes that arrived after a segment was sealed are re-applied from the same records to that segment’s deletion bitmap, so a deleted vector cannot come back on the new replica.
   5. Once within a second of the log head, the replica is marked ready and coordinators start using it. A replica that served before catching up would miss recent writes or show deleted vectors, so readiness is gated on its applied LSN. Full redundancy returns in about a minute for RAM shards; an SSD shard of the big index (~660 GB) takes ~6 minutes, during which its surviving replicas carry it, which is why the largest indexes run three.
5. Switch to a new embedding model. A tenant moves 200 M vectors from a 768-d model to a 1024-d one. Vectors from two models live in different spaces and cannot share an index, so the switch is a second index filled by dual writes and a bulk import, checked, and put behind the alias in one step.
   1. The tenant creates products-v2 with the new dimension and model tag, and starts writing every change to both indexes. Dual writes start before the backfill so that nothing changed during it is missed. Each upsert carries the client’s version, the source row’s update time, and an index keeps only the highest version per id, so an older backfilled copy can never overwrite a newer live one.
   2. The tenant re-embeds its corpus offline and asks us to import the files from its bucket. 200 M vectors at 1,024 dimensions is ~820 GB; pushed through the upsert API at a 15 k/s quota it would take ~4 hours and churn the log for nothing. The import path reads Parquet straight from the customer’s bucket, with a role they grant us, and never touches the log.
   3. Builders read the files, partition rows by hash of the id into the new shards, and build large segments directly. Building straight into ~10 M-vector segments skips the small tiers, so each vector is indexed once: 200 M × ~1.3 ms at 1,024 d ≈ 72 core-hours, about an hour on a few builders. Imports run in a bulk lane of the builder pool, below compactions of live indexes, so a tenant’s backfill cannot slow other tenants’ freshness.
   4. Committing the import tombstones whichever copy of each id has the lower version. Ids dual-written during the backfill exist twice: the live copy in a growing or small segment, the imported one in a big segment. At commit, each imported id is checked against the live segments’ Bloom filters and id tables, and the lower version gets its deletion bit, so exactly one copy of every id matches.
   5. The recall auditor checks v2 against exact search while the tenant runs its own relevance evaluation. These answer different questions. Our audit says the index finds the true nearest neighbours of the new vectors; only the tenant’s labelled evaluation can say whether the new model’s neighbours are better answers. Both have to pass before the switch, and both indexes are audited the same way so a recall difference is never mistaken for a model difference.
   6. The tenant switches the alias, and queries move to v2 as each client instance switches its query model. During the switch the alias maps each model tag to its index, so clients roll the new query model out gradually: a query declaring embed-2027 reaches v2, one still declaring embed-v1 reaches v1, and nothing is answered from the wrong space. Once v1 is retired, a query with the old tag is rejected loudly instead of returning nonsense. Rollback is pointing the alias back.
   7. products-v1 stops getting queries, drops out of RAM and costs only object storage until it is deleted a week later. While both indexes were hot the tenant’s RAM doubled. With storage and compute separated, the old index is evicted ~30 minutes after its last query and falls to ~$0.02 per GB-month, so keeping it a week for rollback costs a few dollars, and rolling back is a cache fill.

Deep dives

The theory behind it

• Approximate nearest neighbour indexes (HNSW, IVF, PQ): How vector databases find similar embeddings fast: why exact search does not scale, HNSW graphs, IVF clustering, product quantisation and other compression, the recall versus latency versus memory trade-off, filtering, updates and deletes, sharding, and choosing parameters.
• Vector search, embeddings and RAG: Embeddings and similarity, approximate nearest-neighbour indexes (HNSW, IVF, product quantisation), vector databases versus adding vectors to your existing store, hybrid search, and retrieval-augmented generation (RAG) pipelines end to end.
• Storage engines, write-ahead logs and durability: What happens inside a database when you write: write-ahead logs and fsync, B-trees versus LSM trees, memtables, SSTables and compaction, read, write and space amplification, group commit, checkpoints and crash recovery.

Related

• Design Zapier
• Design a Recommendation System
• Design a Distributed Logging System
• Design a RAG System
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit