In Haystack, what changes when you swap InMemoryDocumentStore for a database store?

## The protocol is the portable part `DocumentStore` in Haystack is a Python protocol. An implementation must provide: - `write_documents(documents, policy=DuplicatePolicy.NONE) -> int` - `filter_documents(filters=None) -> List[Document]` - `count_documents() -> int` - `delete_documents(document_ids) -> None` - `to_dict()` / `from_dict()` for pipeline serialization Everything an indexing pipeline needs is in that list. `DocumentWriter` calls `write_documents`; your re-index logic calls `filter_documents` and `delete_documents`; your tests call `count_documents`. Swap the object handed to `DocumentWriter(document_store=...)` and the converter, cleaner, splitter, embedder and writer are all unchanged. That is the real payoff of Haystack's explicit wiring: the storage decision is one constructor call, not a rewrite. ## What the protocol does not cover **Construction and connection.** Integration stores live in separate distributions under the `haystack_integrations` namespace, each with its own install and its own constructor arguments — connection strings, index or table names, an option to recreate the index. Those arguments are where all the environment-specific configuration now lives, and they are the part that must be threaded through your deployment config rather than hard-coded. **Vector dimension and distance function.** An in-memory store is happy to hold vectors of any size and picks a similarity function at construction. A database-backed store creates an index or a table with a fixed vector dimension and a fixed distance metric. If the store was created for 768 dimensions and your embedder produces 1536, writes are rejected — and there is no way to "fix" it other than recreating the index and re-embedding. Changing embedding model is therefore an index-rebuild operation, not a config change. **The retriever.** Each store integration ships its own retriever components, because the query has to be expressed in the backend's language. Moving stores means moving the retriever in the query pipeline as well. The rest of the query pipeline — prompt builder, generator — is untouched. **Keyword search.** `InMemoryDocumentStore` implements BM25 in Python, configurable through its own constructor. A search-engine-backed store uses that engine's analysis and scoring instead. Scores are not comparable across the two, and neither are the tokenization rules, so a keyword result set verified against the in-memory store is not evidence about production. This bites hardest in hybrid setups where score fusion is involved. **Filter edge cases.** Every store translates Haystack's filter dicts into its own query language. The common cases behave identically; the edges — missing keys, nulls, numeric-versus-string coercion, nested meta paths — can differ. Validate real filters against the real store. **Lifecycle and failure.** The in-memory store cannot fail to connect, cannot be unavailable, and cannot be shared between processes. A database store can do all three. Errors surface where there previously were none, index creation becomes a deployment step, and two processes writing concurrently is now a real scenario rather than an impossibility. ## Durability, and the testing habit it creates `InMemoryDocumentStore` lives in the process and dies with it, which makes it perfect for tests and for demos; it can also serialize itself to disk and be reloaded, which covers small static corpora. A team that develops entirely against it acquires an unstated assumption — "each run starts empty" — that is false everywhere else. Migrating usually surfaces this as tests that pass alone and fail in sequence, and as re-indexing logic that was never written because it was never needed. ## How to make the swap cheap - Construct the store in exactly one place and inject it into `DocumentWriter` and the retriever. Never construct one inline in a component. - Keep the embedding model and the store's vector dimension declared together, so a mismatch is a config error at startup rather than a write failure in the middle of a batch. - Write the delete-then-write re-index path from day one, against the protocol methods, so it does not have to be invented under pressure. - Run at least a smoke test of retrieval against the real store in CI. Protocol compatibility guarantees the calls work; it guarantees nothing about the ranking you get back. ## The interview answer Say that the protocol makes the *plumbing* portable and the *behaviour* only mostly portable: the writer and indexing chain are untouched, but the retriever, the vector dimension, the keyword scoring and the operational failure modes are all store-specific. Then name the one-way door — changing embedding dimension means rebuilding the index — because that is the decision an interviewer actually wants to hear you anticipate.