sqlite-vec vs ChromaDB vs Pinecone: Choosing a Vector Store for Personal RAG

Thomas Prommer Technology Executive & AI Strategy Consultant Connect on LinkedIn

Published: June 16, 2026

Updated: June 16, 2026

For a personal or single-developer RAG system, use an embedded SQLite vector database (sqlite-vec): the vectors live in the same SQLite file as everything else, there is no server to run, and deploying a new index is copying a file. Reach for ChromaDB when you want a purpose-built local vector store with collections and metadata filtering and accept running a process for it. Reach for Pinecone only when you genuinely need managed scale, high write throughput, or multi-tenant isolation — which most personal projects never reach. The deciding axis is operational burden, not raw capability, and I shipped Ask Tom on sqlite-vec for exactly that reason.

What did I actually choose, and why?

I shipped Ask Tom, a chatbot that answers from everything I have published, on a SQLite vector database — sqlite-vec, a single file, no server. I did not arrive there by benchmarking three products. I arrived there the way you choose training load before a race block: by asking what I am willing to carry, not what is theoretically fastest. A managed vector service is a faster engine I did not need and a recurring cost I would feel, in exchange for scale I will never use on a personal corpus.

That is the whole argument of this piece, and it is deliberately not a feature shootout. All three of these can store an embedding and hand you its nearest neighbours — that part is solved. What differs, and what actually decides a personal build, is what you have to run, bill, and get paged for. So the comparison below is organised around operational burden, because that is the number that stopped measuring the thing the moment people started ranking vector stores by raw capability instead.

What are the three real options?

They are not three competitors on one shelf; they are three points on a single axis of how much you run. Embedded is a file in your process. Local-server is a process you operate. Managed is a service someone else operates and bills you for. Knowing which tier you are in matters more than which brand you pick inside it.

• Embedded — sqlite-vec. The vector store is a vec0 virtual table inside an ordinary SQLite file. Nothing extra runs; the "database" is bytes on disk you can copy and back up like any other file.
• Local server — ChromaDB. A purpose-built vector store you run as a process, with collections, metadata filtering, and a Python-native API designed for retrieval workloads.
• Managed cloud — Pinecone. A hosted, horizontally scalable vector service. No process to operate, a network hop per query, and a monthly bill that buys scale and isolation.

How do they compare for a personal build?

Scored for the personal-RAG use case specifically — a single small-to-medium corpus, read-heavy, one operator. A different use case (a multi-tenant SaaS, say) would score these in almost the opposite order, which is exactly the point: the "best" vector store is a function of the burden you are sized for.

Read down the columns and the verdict is not subtle. For one person and one corpus, the embedded store wins every row that costs you time, and loses only the rows — scale ceiling, fancy filtering — that a personal build does not cash in. That asymmetry is the whole decision.

When is sqlite-vec the right call?

When your corpus is a few thousand to low-tens-of-thousands of chunks, the workload is read-heavy, and there is one of you. That describes almost every personal knowledge base, including mine. The win is not that sqlite-vec is the fastest engine — it is that the vector store stops being a moving part. There is no process to keep alive, no account to provision, no separate backup story. The vectors live in the same SQLite file as the rest of the data, so the entire deployment story for a fresh index is: build it locally, scp the file, bounce the API.

I keep coming back to the same discipline I use for training load: spend complexity only where it changes the outcome. A managed vector database does not change the answers Ask Tom gives over a few thousand chunks; it only adds a bill and a dependency. So the embedded store is not a compromise I settled for, it is the correct sizing for the load — the same reason you do not bring a team time-trial bike to a parkrun.

When does ChromaDB start to make sense?

When you want the batteries that a hand-rolled vec0 table does not ship with, and you accept running a process to get them. The clearest trigger is metadata: if your retrieval needs to filter on structured fields — source, date, author, document type — at query time across several distinct collections, Chroma is built for exactly that and saves you writing and maintaining the SQL by hand. It is the right pick the moment "manage several corpora with real filtering" becomes a recurring need rather than a one-off.

The honest counterweight is that you have crossed the line from "the vector store is a file" to "the vector store is a service I operate," even though that service runs locally. You now have a process to start, persist, monitor, and back up on its own terms. For a single small corpus answering plain similarity queries, that is overhead with no payoff. For several corpora with genuine filtering, the overhead buys something real. The boundary is whether the filtering and multi-collection ergonomics are load-bearing in your build or just nice to have.

When is Pinecone worth the bill?

When you have genuinely outgrown a single machine — and not before. Pinecone is a managed, horizontally scalable vector service, and the things it sells are the things a personal RAG does not need: high write throughput, multi-tenant isolation, elastic scale, and the freedom to not operate the store yourself. If you are building a product where many users each have their own large, frequently-updated corpus, those stop being luxuries and become the requirement, and a managed service is a reasonable answer.

For a personal build, paying that bill up front buys you scale you will not use, isolation you do not need (one tenant), and a network hop on every query — in exchange for problems you do not have. That is the inverted version of the sqlite-vec case: where embedded is correct sizing for a small read-heavy load, Pinecone is correct sizing for a large multi-tenant one. Most personal RAG systems live their entire life in the first regime. If yours genuinely crosses into the second, the upgrade is not a rewrite — you swap the storage layer and keep the chunking, embedding, and retrieval logic intact.

So how do I actually decide?

Start from burden, not benchmarks. Ask how big the corpus really is, whether it is read-heavy or write-heavy, how many tenants it serves, and which failure mode you are willing to own at 3am. For one person, one corpus, mostly reads, the answer is the embedded SQLite vector database, because the part of a system you most want to be boring is the part that holds your data — and a file is the most boring, most copyable, most recoverable thing it can be.

If you want the worked example behind this verdict — the actual pipeline, the vec0 table, the chunking knobs — it is all in Build Ask Tom: A RAG Chatbot on One SQLite File. If you are upstream of the build and still deciding whether a citable knowledge base earns its keep at all, I made the strategy case in Build a Second Brain That Answers Back on ctaio.dev. And if you would rather see the whole field ranked than take my single opinionated call, the We The Flywheel Radar on AI knowledge-base tools is the place to compare.

FAQ