Topic 5.8
Choosing a Store
In one line
Choose from what you already run, how big your data is, which filters and keyword search you need and who will operate it. Put the store behind an interface so the choice can be reversed.
Think of it like this
Choosing how to travel to work. If the office is two streets away you walk. If you already own a bicycle, you cycle. A bus fits many people but runs on its own timetable. Nobody buys a train line first. Pick the smallest thing that gets you there, and keep a way to change later.
Words you'll meet
New words in this topic, in plain English. Come back here whenever one feels fuzzy.
- Operations burden
- The ongoing work of running a system: upgrades, backups, monitoring and fixing it at night.
- Adapter
- A small class that makes one product fit your interface.
- Vendor lock-in
- Being stuck with a product because moving would cost too much.
- Proof of concept
- A small trial on your own data to check that an idea works.
- Headroom
- Spare room for growth beyond today's numbers.
- Hybrid search
- Keyword and vector search combined (Phase 6).
Step by step
01Step 1: describe the project as a profile
Write down vectors, dimensions, memory of the machine, whether you run PostgreSQL or a search engine, whether you need keyword search, and whether anyone can operate a cluster. The example turns each into a field.
02Step 2: estimate the memory
The example reuses the sizing from Topic 5.7. 'Fits' means the estimate is at most half of the memory, an assumption you should change.
03Step 3: walk the rules in order
Small and single-process: embedded. Already on PostgreSQL and fits: pgvector. Has a search engine and needs keyword search: vector fields there. No ops team: managed dedicated. Otherwise: self-hosted dedicated.
04Step 4: read the five answers
The handbook bot gets an embedded library with 8.4 MB. Case B has 2 million vectors on PostgreSQL and fits, so pgvector. Case C has 1536-number vectors: they no longer fit, so the search engine rule applies. Cases D and E need hundreds of gigabytes and differ only in who can run it.
05Step 5: treat the result as a first guess
The rules are a thinking aid. Their order and the 'half of memory' limit are choices made for the example. A real decision also weighs price, licences, security review, data location and the team's experience.
06Step 6: plan the way out
Before you commit, write the adapter list: which methods does the application need (upsert, delete, search with filter, count), and which product feature does each map to. Anything you cannot map is the lock-in.
Try it yourself
- 1
Change a profile
Make case B's RAM 4,000 MB and run. Which rule fires now? Then give B an ops team too.
- 2
Add a rule
Add a profile with a strict data-location requirement and a new rule 'self-hosted only' ahead of the managed rule. Write which fields you need to add.
- 3
Check your own project
Fill in a profile for a project you know and read the answer. Do you agree? What did the rules not know?
Code & diagrams
A thinking tool, not an oracle: the order of the rules and the 'half of memory' limit are assumptions to change for your own situation.
Expected output
A handbook bot: 8.4 MB -> an embedded library or a plain file
B product with PostgreSQL: 3344.0 MB -> pgvector in the PostgreSQL you already run
C big vectors, has a search engine: 12560.0 MB -> vector fields in your search engine (keyword and vector in one query)
D huge, no ops team: 501600.0 MB -> a managed dedicated vector database
E huge, with ops team: 501600.0 MB -> a self-hosted dedicated vector databaseBreak it on purpose
Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.
Break #1
Hard-code the dimensions
In the Python tab, change 4 * dims inside estimate_mb to 4 * 384, as if every project used the same model. Run.
Myth vs fact
Myth
The best vector database is the one at the top of a ranking.
Fact
Rankings use other people's data and hardware. Test the top two on yours.
Myth
A dedicated vector database is always the professional choice.
Fact
A table in a database you already operate is professional too, if it meets your needs.
Myth
Migration is impossible later.
Fact
It is routine with source documents, a repeatable ingestion and an interface. It is painful without them.
Pro corner
Extra depth for experienced readers. New to this? Skip it for now and come back later.
- ▸
Check exit as carefully as entry: can you export every vector and payload? How long does a full re-index take at your size, and does the new system accept the old vectors?
- ▸
Test failure, not only success: kill a node, restore a backup, run a compaction under load. A store you have not seen recover is a guess.
- ▸
Security review: where does the data live, who can read it, is it encrypted at rest and in transit, and can you delete a user's data on request (Topic 5.6)?
Remember this
- 1
Why this topic exists. Topic 5.3 named the families. This one turns them into a decision you can write down. The most common mistakes are choosing a product because a blog ranked it first, and choosing the biggest system for a small problem. Both come from skipping the questions below.
- 2
Question 1: what do you already run? A team that operates PostgreSQL well gets a lot by adding pgvector. A team that runs Elasticsearch or OpenSearch gets keyword and vector search in one place. A new system is new work: accounts, upgrades, backups, monitoring, on-call.
- 3
Question 2: how big, and how fast does it grow? Size the data (Topic 5.7) at today's numbers and at ten times. If it fits comfortably in one machine's memory, almost every family works. If it does not, shards and replicas matter, and the answer moves toward systems built to scale across machines.
- 4
Question 3: what filters and search types do you need? Strict per-user filters (Topic 5.5), keyword plus vector (Phase 6), several vectors per item, or live updates all narrow the list. Read each candidate's documentation for exactly those features, and test them with your data.
- 5
Question 4: who operates it? Managed services trade money and some control for less work. Self-hosting trades work for control and often a lower bill at large scale. A small team with no one to run a database should be wary of a self-hosted cluster.
- 6
Question 5: what is the cost of leaving? Keep the source documents and the model name, write all store access behind a small interface (
VectorStore, Topic 5.9) and keep the ingestion pipeline repeatable (Topic 4.7). Then migrating means writing one adapter, running ingestion and comparing results, not rewriting the application. - 7
Decide with a test, not an opinion. Build a test set of real questions with known right passages (Phase 9). Load the same data into the top two candidates and compare recall, latency at your load, and the work it took. A benchmark published for someone else's data and hardware is not evidence about yours.
Explain it without notes
Why is "what do we already run?" the first question?
How does an interface keep the choice reversible?
Why not trust a published benchmark to choose a store?
When is an embedded library the right answer?
Practice
Add a field must_self_host to the idea of the guide and write recommend2(profile) that returns "self-hosted dedicated" whenever it is true and the data does not fit in one process, and otherwise calls your earlier rules. Print the answer for a profile with must_self_host=True, fits=False.
List the methods your application needs from a store for AskDocs (at least four) and write a Python Protocol or abstract class VectorStore with them. Print the method names.
Trade-offs
- ↔
Reuse what you run: least new work, shared resources and limits.
- ↔
A new dedicated system: purpose-built features, one more thing to operate.
- ↔
Managed service: less operations work, ongoing cost, data leaves your network.
Done when you can
Done when you can list the five questions that decide a store.
Done when you can write a profile of a project and justify a family for it.
Done when you can explain how an interface and repeatable ingestion make migration cheap.
Done when you can say why you would test two candidates on your own data.