A vector database answers a single question: "which stored vector is closest to this one?" That is the basis of search by meaning — you store the text chunks as embeddings, turn the question into a vector too, and the system gives back the nearest ones. Everything else it offers — filtering, metadata, versioning — is built around that.
Two numbers are worth knowing about size. Ten thousand vectors take roughly 75 megabytes — that fits on a phone. And by a vendor's own capacity planning formula, the graph that speeds the search up is 5% of total memory: 0.29 GB of index next to 5.72 GB of vectors. Memory goes on the vectors, not on the index.
The most common misconception follows from that: that vector search needs a database of its own. For most projects starting out it does not — the established relational databases can store and search vectors today, and the real cost is often not the technology but the monthly minimum of a separate service.
When you genuinely do need a separate system is the subject of Vector Databases Without the Jargon, a separate article. Directly related terms: embedding, retrieval and hybrid search.