Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.insitechat.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Definition

A vector database is a specialized data store that holds high-dimensional vectors (embeddings) and supports fast nearest-neighbor search across millions or billions of them. It is the storage layer that makes retrieval-augmented generation (RAG) feasible at scale — without a vector database, finding the most relevant passages for a question would require scanning every chunk of content on every query. Vector databases are to embeddings what traditional databases are to rows: they let you search huge collections in milliseconds, with indexes, filters, and updates.

​
Why traditional databases aren’t enough

Relational databases (PostgreSQL, MySQL) and document stores (MongoDB) are built for exact match, range queries, and joins on structured fields. They are not optimized for the question “which of these 10 million vectors is closest to my query vector?”. Vector databases use specialized index structures — Hierarchical Navigable Small World graphs (HNSW), Inverted File Index (IVF), Product Quantization (PQ) — to make approximate nearest-neighbor search both fast and memory-efficient. A typical query latency on a vector database:
Collection sizeLatency (HNSW index)
10,000 vectors< 1 ms
100,000 vectors1-3 ms
1 million vectors5-15 ms
10 million vectors20-50 ms
This makes vector search fast enough to run inside a chatbot’s response loop without the user noticing.

​
Common vector databases

  • pgvector — a PostgreSQL extension, popular for teams already on Postgres
  • Pinecone — fully managed, serverless, premium pricing
  • Weaviate — open-source with managed cloud option, schema-aware
  • Qdrant — open-source, Rust-based, fast
  • Milvus — open-source, designed for massive scale
  • Chroma — open-source, simple, popular for prototypes
  • Elasticsearch / OpenSearch — added vector search to existing keyword stores

​
What InsiteChat uses

InsiteChat runs on pgvector — PostgreSQL with the pgvector extension. This choice was deliberate:
  • Single source of truth: chatbot config, conversations, leads, and content embeddings live in the same Postgres database. No two-store synchronization problem.
  • ACID guarantees: deleting a source removes its vectors atomically with its metadata; no orphan vectors after partial failures.
  • Operational simplicity: backups, replication, and monitoring use the standard Postgres toolchain.
  • Cost efficiency: no extra managed service to pay for, no separate pricing per vector.
  • Performance at our scale: pgvector with the HNSW index easily handles every InsiteChat customer up to tens of millions of chunks.
If we outgrow pgvector at the high end, the migration path to a dedicated store like Qdrant or Weaviate is well-documented. We have not needed it.

​
How chunks become searchable

When you add a source to your chatbot in InsiteChat:
  1. The crawler/uploader extracts text.
  2. The text is split into chunks (512 tokens, 50-token overlap).
  3. Each chunk is sent to an embedding model and the resulting vector is stored alongside the chunk text in pgvector.
  4. An HNSW index is updated to make the new vectors searchable.
  5. At query time, the visitor’s question is embedded and the index returns the top-K nearest chunks in milliseconds.
You never interact with the vector database directly — InsiteChat’s hybrid search layer sits in front of it and combines vector search with keyword (BM25) search for accuracy.

​
Learn more