Search your own documents with AI
This layer is where your information lives and how a build finds the right piece of it fast. A helper is only as good as what it can look inside, so before anything answers a customer, your files and records get loaded into a store it can search. The search works two ways at once: by exact words, the way you would expect, and by meaning, so an oddly worded question still lands on the right paragraph. That is what lets the build behind "Find anything in your own documents in seconds" pull back the right passage from years of files, and what lets a website helper answer from your approved information and nothing else. Word documents, PDFs and the records that were never meant to be searched all get turned into something a build can read.
Postgres
A long-established, dependable database: the filing cabinet where a build keeps its information in order. It is the store that holds the material a helper answers from and the records the automations read and write. It is boring in the best way, which is exactly what you want holding your data.
pgvector
An add-on that gives Postgres a new sense: the ability to search by meaning, not just by exact words. It is what stores the "meaning" version of your documents so a build can find the right passage even when a question is worded nothing like the text. This is a core piece of the search behind "Find anything in your own documents in seconds".
HNSW
The method that makes search-by-meaning stay fast once there is a large pile of documents to look through. Checking a question against every passage one at a time gets slow at that size, so this organises them into a structure a build can jump straight through to the closest matches. I have built and tuned this inside a live production system. When a narrow search there was quietly missing the right passages, I found the setting that controls how hard the index looks, turned it up, and those searches went from finding none of the right answers to finding all of them.
BM25
BM25 is the well-known approach for ranking results by their exact words, the kind of matching you already know from looking things up. In the builds this keyword ranking is done by the database's own full-text search, working in that same style. It runs alongside search-by-meaning so both go at once: exact terms are caught the obvious way, and the meaning search catches the rest. Together they are why an oddly phrased question still lands on the right paragraph.
Supabase
A hosted, managed version of Postgres with the surrounding parts a build needs bundled in. It saves standing up a database from scratch, which means less to maintain and one less thing that can quietly break. Where a build uses Postgres, this is often where that Postgres lives.
SQLite
A tiny, self-contained database that lives in a single file, with no separate server to run. It is the sensible choice when a store needs to be small, local and simple rather than large and shared.
node-postgres
The standard connector that lets a build written in Node talk to a Postgres database. It is pure plumbing: it carries the read and the write between the code and the store. Nothing a customer sees, but nothing works without it where Node and Postgres meet.
mammoth
A small tool that turns Word documents into clean text a build can read. Owners live in Word, and Word files are messy under the hood, so this is one of the first steps in getting your documents ready to search. It feeds the ingestion behind "Find anything in your own documents in seconds".
unpdf
A tool that pulls the text out of PDF files. So much of what a business keeps is locked in PDFs: contracts, manuals, old records. This gets that text out so it can be searched, and it is another feeding step for the document search.
pdf-lib
A tool for building and editing PDF files from scratch. Where the others read PDFs, this one writes them, turning tidy information into a finished document. It is the piece behind generating a clean, consistent quote in "Get quotes and proposals out the door faster".
gpt-tokenizer
A small tool that counts text the way a model counts it, in units called tokens. That sounds technical, and to you it is invisible, but it is how a build measures how long a document is before sending it, splits it into the right-sized pieces, and estimates what a job will cost before running it.