Vector Database

Search was character matching for a long time. If the words a user typed appear in the document, it's found; if not, it isn't. Write the same meaning in different words and the document effectively ceases to exist.

Pagedeck's help center put a number on that limit. Reading the search logs, 40 percent of searches returned zero results, and most of those covered topics the documentation actually had. A user typed "how do I request time off" while the document was titled "Vacation request procedure." With no characters in common, search produced nothing, and the user concluded the answer wasn't written anywhere.

What was needed was comparison by meaning rather than by characters. Converting a sentence into a list of numbers puts sentences with close meanings at close numbers, which is the idea behind embeddings. An embedding is meaning represented as a numeric vector. "Time off" and "vacation" share no characters, but as numbers they land near each other.

The problem came next. With 500,000 document chunks, one question means 500,000 comparisons, and each comparison means matching 1,536 numbers. Scanning all of them in an ordinary database takes seconds per search, which is well past what anyone will wait for a search box.

Making meaning-based search fast enough to actually ship is what this tool is for. Four things happen inside it.

1. Vectors are stored as vectors. One row is a list of 1,536 numbers, with the original text chunk and its source attached. In an ordinary database that list is treated as one opaque array, so no index usable for comparison can be built on it.
2. It finds without comparing everything. An index known as approximate nearest neighbor is built in advance, candidates get narrowed sharply, and comparison happens only inside that set. Approximate means accepting a small chance of missing the very closest match. A search that took three seconds scanning 500,000 rows takes 20 milliseconds. Accuracy drops into the mid-90s, which barely shows when the job is presenting the top five results. It would show if the job were proving that no closer match exists.
3. It searches with conditions attached. Most real cases need only this customer's documents, or only the last year. In a multi-tenancy arrangement the condition is also a safety mechanism — multi-tenancy is several customers sharing one system, and without the filter another customer's documents appear in the results.
4. It keeps accepting writes and deletes. Editing a document changes that chunk's vector. Some index designs are expensive to rebuild and others update incrementally, so frequently changing documentation makes this the property to check first.

With those four in place a RAG pipeline becomes possible. RAG is retrieving outside material and attaching it so a model can compose an answer. Documents get chunked and stored as vectors; when a question arrives it also becomes a vector, and the nearest chunks get pulled and handed to the model. The database is the retrieval half of that arrangement and nothing more.

A dedicated product isn't the only route. The choice among four comes down to volume and latency requirements.

1. Add an extension to the database you already run. A relational database stores data as tables and relations, and a vector extension brings similarity search into the same place. Up to a few hundred thousand chunks that's enough, and the number of systems to operate doesn't grow — which for a small team is usually the deciding factor.
2. Run a dedicated vector database alongside. It earns its cost past a few million chunks or when latency must stay inside tens of milliseconds. In exchange, the source data and the vectors live in two places and have to be kept in sync, which is its own class of bug.
3. Use the vector features bolted onto a search engine product. If a search engine is already running for full-text search, character search and meaning search can run in one place.
4. Keep character search as it is. For product codes, people's names, and contract numbers — anything where an exact match is the point — meaning-based search is actively worse. Running both and blending the results often works better than either alone, and costs less than replacing one with the other.

Three criteria decide it: chunk count, tolerable latency, and whether anyone is available to operate one more system. Most teams overestimate the first and underestimate the third. Starting at option 1 and moving once you hit its limit generally costs less.

"Let's just add the vector extension to the database we have. Eighty thousand chunks is fine."

Small enough in scale to start without a dedicated product.

"Search takes 20 milliseconds and generating the embedding takes 400."

The bottleneck sits in the conversion step, not the database.

"We searched without the customer filter and another company's documents came back."

The condition was missing, so isolation broke.

Pagedeck put this behind help center search. Theo split 400 documents into paragraph-level chunks, produced 8,000 of them, and installed the extension on the existing database. Searches returning zero results fell from 40 percent to 6.

Looking into the remaining 6 percent, Mia found most were cases where someone typed a feature name correctly and the documentation never used that name. Meaning-based search couldn't reach those either; the documentation had to change. So the list of failed searches became the basis for deciding which help articles to write, which turned a search metric into a documentation backlog.

The most common reading is that adding this tool improves search. Describing it as searching by meaning sounds like a promise about result quality. But all this store does is quickly find which of the given vectors are close together. Result quality is set by which model produced the vectors and how the documents were chunked. Turn a whole document into one vector and its meaning smears until every query returns that document. Finding a bad vector quickly does not make the answer better.

Treating it as a replacement for character search is also frequent. Meaning-based search arrived later, so it looks that way. But the two are good at different things. When one character's difference means a different answer, as with contract numbers or error codes, matching characters is exact, while meaning-based search returns a similar-looking different number. So real products run both and sort on a combined score.