A Review of Pinecone:
748 Files, 2,367 Vectors, Two Rebuilds

I came to Pinecone knowing nothing. My plan, in full, was "get the PDFs, throw them in a database, let the AI search them." I assumed that database would be SQL, because every database I'd built in twenty-odd years had been.

The answer I got was "yes and no." Yes, you can put documents in SQL. No, that won't let an AI search them the way you're imagining. For that you need a vector database, and I had to go and find out what that meant.

Chunks, and Why the Word Matters

A vector database doesn't store your documents. It stores chunks of them. A PDF gets broken into bite-sized pieces of raw text; a web page gets stripped of its HTML first and then cut the same way. Each piece is converted into a long list of numbers that captures roughly what it means, and it's those numbers that get searched.

That distinction sounds academic until it hits your dashboard. Pinecone counts records, and a record is a chunk, not a file. So when the console tells you there are 932 records in an index, that could be 900 documents or it could be 64. In my case it's 64.

Here is what that actually looks like across my four indexes, and it's the most useful table in this review because nobody publishes it:

Look at that last column. Same account, same settings, and the ratio swings from 1.6 to 19. Scraped web pages are thin — a page of marketing copy is barely more than one chunk. Dense multi-page documentation explodes into fifteen or twenty. So if you're trying to estimate how big your index will be, your file count tells you almost nothing. Density does.

What Five Months Actually Consumed

All 748 files occupy 0.011 GB of the 2 GB free allowance. That's about half of one percent. I could put roughly a hundred and eighty times more in there before storage became a conversation.

Reads are measured in Read Units, and I have a million a month. Near the end of July, with a week still to run, I'd used 489.

I want to be honest about what that number means, because it flatters me. Most of the sites drawing on these indexes are still in testing, one of my tools uses PostgreSQL rather than Pinecone entirely, and the user base is me plus a handful of colleagues. This is not production traffic.

Still — if I scale it out, six people generating 489 read units means around six thousand people would generate 489,000. Which would still fit inside the free tier. Rough arithmetic on unrepresentative data, and I'd expect real usage to be spikier. But it reframes the question. The free tier isn't a teaser that runs out the moment you're serious; for an internal tool at a mid-sized company it may simply be the answer.

The Rebuild Nobody Warned Me About

An index has a dimension — the length of those number lists — and it has to match the embedding model you use. Mine are all 768, matching the model I settled on.

I didn't know that the first time. The choice is presented as a number you pick, and the intuition it invites is wrong: smaller sounds faster, bigger sounds better. Neither is the point. The point is compatibility, and nothing in the flow told me so.

I picked one, built the whole index, connected it, and found it wouldn't work with the model I'd chosen. There's no converting your way out of that. You tear it down and start again.

The Rebuild That Was My Fault, Sort Of

The second teardown was more interesting, because everything appeared to be working.

The company has two similar products. They share terminology heavily — the same words for the same concepts, with meaningful differences in the details. As the index filled up, I started noticing answers about one product surfacing for questions about the other.

My first reaction was indignant. But it says so in the document. And it did. That's not how retrieval works, though. Every chunk gets scored for relevance, and the winning chunk had matched on nearly everything — topic, phrasing, context — while the one detail that distinguished the two products carried no particular weight. So the search did exactly what I'd built it to do, and gave the wrong answer confidently.

So: tag everything. Product. Industry. Document type. Audience. State or region if anything varies by it. Anything at all that makes a document distinguishable from a similar one. Every tag you add is a lever the retriever can use to tell two near-identical chunks apart.

That's my single biggest recommendation, and I had to learn it by getting it wrong in front of people. It appears nowhere prominent in Pinecone's own material.

The Console Won't Tell You How Many Documents You Have

This is the complaint I keep coming back to.

The index list tells me the cloud, the region, whether it's dense, the capacity mode, and the dimension. All useful. It does not tell me how many files are in there. It tells me how many records — chunks — which, per the table above, is a number I can't reliably work backwards from.

And there's no file-level view at all. You can't open a document to inspect it, edit it, or delete it. You see chunks. If you want to remove one PDF you go hunting for every chunk belonging to it, and the obvious question arrives immediately: what if I miss one? A stray chunk with no tags is exactly the thing that surfaces in a search it has no business being in.

So I built my own tool. It talks to the API, groups chunks by their source file, and tells me what the console won't: 153 files, 338 vectors. That's where every number in this review comes from. It works well — the API is genuinely good, which I'll come back to — but I shouldn't have had to write it.

Deleting Is Genuinely Broken

Rebuilding meant removing the untagged versions and replacing them. That's when I found that deletion doesn't reliably work.

I'd issue a delete through the API and the record would still be there. The workaround I stumbled into was absurd: add the replacement first, delete that, and then the original would go. I still don't understand why.

And there are a couple of records I have never managed to delete. They're still in there now. They're duplicates of documents that exist properly elsewhere, so my fix was to tag the orphans in a way that guarantees they can never match a real query. It works. It is not a fix.

The Documentation Is Shockingly Sparse

I'm confident good documentation exists somewhere. I've had a hard time finding it.

The best tools are intuitive, or they have enough flow that you can feel where you're going, and where help is needed there's an actionable hint sitting right next to the thing that needs explaining. Pinecone doesn't do that. You go on a scavenger hunt.

The nuances are what's missing, and the nuances are what cost you a weekend. Add as many tags as you can. Your dimension has to match your model. Chunk size matters more than you think. Those three sentences would have saved me two rebuilds. You can argue I should have done more due diligence, and you'd have a point. But I read what there was, and it didn't say these things.

The Retrieval Worked. The Documents Didn't.

This is the thing I'd most want someone to take away, and it has nothing to do with which vector database you choose.

Once I had the pipeline running, I discovered the source material was the problem. The documentation had been written for people who already knew the system. It gave precise instructions and skipped the basics, because the basics were covered in training, and training materials were tailored per customer.

Worse, the products themselves are configurable — think of a set of switches turned on or off per client. No two deployments are quite the same, and there was no document describing the product with nothing switched on. The base case, the thing a newcomer actually needs, had never been written down, because internally nobody ever needed it.

You cannot retrieve an answer that was never written. No amount of chunking, tagging, or model choice fixes a knowledge base that assumes the reader already knows.

If you're planning something like this, audit your documents before you pick a vendor. Ask whether a brand-new person could answer their own question from what you've got. If the honest answer is no, that's your project — the database is the easy part.

What I'd Look At Now

When I started, I compared Pinecone against a handful of managed vector databases on price. Several wanted a substantial commitment up front, which is an awkward ask for something you can't yet prove will work. Pinecone's free tier removed that question entirely, and that's genuinely why I'm on it.

What I didn't know then is that you may not need a dedicated vector database at all. PostgreSQL handles vectors now, and I already had PostgreSQL sitting unused on my own server for years without noticing. One of my own tools now runs on it rather than Pinecone. There's also SQLite, which can act as a vector store — that one genuinely surprised me. If your corpus is small, a file on your own disk may be the whole answer.

There's a second reason I keep circling that: control. Everything I've indexed so far is public — website content and documents we hand out freely — so an outside service is a fine place for it. The moment anything sensitive is involved, I'd want it in-house. Not paranoia; just that every external service is one more party holding your material.

I haven't run those alternatives at length, so I can't tell you they're better. I can tell you they exist, which is more than I knew in February.

Who Should Use Pinecone

Yes, if you're proving out an idea and can't justify spending money to find out whether it works. The free tier is real, not a trial — 748 files at $0 across five months. It's fast. The API is excellent, and if you're building your own tooling on top, that matters more than the console does.

Yes, if you arrive prepared. Tags planned, dimension matched to your model, chunk size chosen deliberately, indexes mapped out. Do that and it's smooth — you go in, set it up, and it works.

Think twice if you expect to iterate messily, which is what actually happens the first time. Rebuilding is where the sharp edges live: no file view, unreliable deletes, a console that can't tell you what's in your own index.

Probably not, if your corpus is genuinely small or your content is sensitive. PostgreSQL or SQLite on hardware you control may do the job with one fewer party involved.

What I can't tell you: how it behaves under real load, whether support is any good, how the paid tier compares, or how it stacks up against competitors. I've run one free account for five months. Anyone reviewing past their own experience is guessing.