ai-architecture
comparison
05 Sept 2026
Six vector stores, compared on how many vectors the free tier really holds
Every one of these advertises its free tier in gigabytes. Nobody embeds gigabytes. Converted into vectors at a common dimension, the gap between the most and least generous is about forty times.
By Purvansh Parmar
Checked 2026-09-05
Read 9 min
Entries 6
Ask how big a vector free tier is and you get an answer in gigabytes. That unit is useless. Nobody has a gigabyte of embeddings; they have a number of documents, and the two are related by a constant nobody puts on the pricing page.
The constant is the dimension count multiplied by four bytes. At 1536 dimensions, the size OpenAI's widely used embedding model produces, one vector is 6,144 bytes. So a 2 GB allowance is 349,525 vectors, a 500 MB allowance is 85,333, and both numbers halve once you build the index that makes them searchable. Below, each free tier is converted the same way.
How this was checkedI did the conversion against a real 500 MB Postgres allowance I set up the same day, using measured row sizes rather than estimates. A 1536-dimension float32 vector is 6,144 bytes, so 500 MB holds 85,333 of them before any index exists. Add an HNSW index, which is commonly the same order of magnitude as the vectors it covers, and the working figure is closer to 42,000. The advertised number and the usable number differ by half before you store a single piece of metadata.
What I compared on
- capacity expressed in vectors at 1536 dimensions, not in gigabytes
- whether an index is included in that budget or on top of it
- the cheapest paid step, and whether it is a plan or a meter
- what happens to the data when you stop paying attention
Managed vector search that hides the index entirely.
Free
Starter gives 2 GB of storage, 1 million read units and 2 million write units a month, across up to 5 indexes. That is roughly 349,000 vectors at 1536 dimensions.
Paid
Builder is a flat 20 dollars a month, which is the most predictable first step in this comparison.
Wins
The largest free capacity here by a wide margin, and the only one where the index is not something you budget for separately. Five indexes on the free tier also means you can keep staging separate from production without paying.
Loses
Read and write units are the real limit and they are hard to predict from a document count. A million reads sounds enormous until a re-ranking step queries the same index five times per user question, at which point it is 200,000 questions.
2 GB~349,000 vectors1M reads/mo$20/mo
The open-source engine, run for you on a small always-free node.
Free
A single node with 0.5 vCPU, 1 GB of RAM and 4 GB of disk, described as free forever. Disk is the generous part; RAM is what actually bounds you.
Paid
Usage-based rather than a plan, sized with a calculator, so the first step up is whatever your cluster needs rather than a fixed number.
Wins
Free forever with no expiry and no object ceiling, and the same engine runs on your own hardware, so leaving is a migration rather than a rewrite. That exit path is worth more than a larger free tier.
Loses
Half a vCPU and 1 GB of RAM is a demonstration node. HNSW wants the graph resident in memory, so the 4 GB of disk is misleading: you will hit the RAM wall long before you fill the disk, and the failure looks like latency rather than an error.
1 GB RAM4 GB disk0.5 vCPUfree forever
Vector search with a built-in embedding service and query agent.
Free
100,000 objects, 1 GB of memory and 10 GB of disk, always free, plus 2,000 embedding requests a day and 1,000 query agent calls a month. One collection, up to three tenants.
Paid
Flex starts at 45 dollars a month, pay as you go with no commitment, which is the highest entry price of the managed options here.
Wins
It states its free tier in objects rather than bytes, which is the honest unit and the only one on this page that does it. Including 2,000 embeddings a day also means you can prototype without a second vendor.
Loses
One collection. Not one index, one collection, so separating documents from chat history means paying, and 45 dollars is a steep first step from free when the alternatives start at 20 or at nothing.
100,000 objects1 GB memory2,000 embeddings/day$45/mo
The embedded library most prototypes start on, now with a hosted tier.
Free
5 dollars of credit rather than a capacity. At 0.33 dollars per GiB per month for storage, that credit covers roughly 15 GiB-months if you never write or query, which of course you will.
Paid
Metered throughout: 0.33 dollars per GiB stored per month, 2.50 dollars per GiB written, 0.0075 dollars per TiB queried and 0.09 dollars per GiB returned.
Wins
Query pricing is close to free in practical terms, and the local library is the same API, so the prototype you already wrote on your laptop moves without changes. Storage at 33 cents a gigabyte is the cheapest rate here.
Loses
Writes cost 2.50 dollars per GiB, which is roughly 7.5 times the monthly storage rate for the same data. Re-embedding a corpus is therefore the expensive operation, and re-embedding is exactly what you do every time you change models.
$5 credit$0.33/GiB-mo$2.50/GiB written
Vector search built on object storage rather than resident memory.
Free
None. The entry plan carries a 16 dollar monthly usage minimum, and there is no free capacity to start on.
Paid
Launch is a 16 dollar a month minimum, Scale is 256, and enterprise begins above 4,096 with a usage premium on top.
Wins
Sixteen dollars a month with no free tier is honest, and it is less than Weaviate's first paid step. Building on object storage rather than RAM is also why the cost curve stays flat as the corpus grows, which is the opposite of everything else here.
Loses
There is nothing to try before you commit, and no way to leave teh meter running at zero over a quiet month. For a project that might not happen, a 16 dollar floor is infinitely more than free.
no free tier$16/mo minimum$256/mo at Scale
An extension that makes Postgres store and search vectors alongside your rows.
Free
Whatever is left in your existing database. On a 500 MB managed Postgres allowance that is 85,333 vectors at 1536 dimensions, or about 42,000 once an HNSW index exists.
Paid
Nothing extra. You pay for the Postgres you were already paying for, and the next step up is the next database tier.
Wins
One system, one backup, one connection, and joins between a vector and the row it describes without a second round trip. For anything under roughly 100,000 documents this is the correct answer and the other five are solving a problem you do not have.
Loses
The index is where it stops. Building HNSW on a small managed instance is slow and memory-hungry, and the shared plan you are on was sized for rows rather than for graph construction, so the build is what falls over rather than the queries.
85,333 vectors in 500 MB~42,000 with an index$0 extra
Side by side
| Store | Free capacity | As vectors at 1536d | Cheapest paid |
|---|
| Pinecone | 2 GB, 5 indexes | ~349,000 | $20/mo |
| Qdrant Cloud | 1 GB RAM, 4 GB disk | RAM-bound, not disk-bound | usage |
| Weaviate | 100,000 objects | 100,000 | $45/mo |
| Chroma Cloud | $5 of credit | depends on write volume | metered |
| turbopuffer | none | 0 | $16/mo |
| pgvector | your spare database | ~85,000, ~42,000 indexed | $0 extra |
Verdict
pgvector, until it stops working. If your corpus is under about 100,000 documents you already own the right database, and adding a second system buys you a migration, a second backup and a join you now have to do in application code. When you outgrow it, go to Pinecone: 2 GB free is genuinely the largest capacity here and 20 dollars flat is the only first step that does not require a spreadsheet. Choose turbopuffer when the corpus is large enough that keeping an index in RAM is the cost driver, because that is the one problem it is built for. And convert every free tier into vectors before you believe it.
Sources