pgvector is an open-source extension for PostgreSQL that adds a vector column type, distance operators for cosine, Euclidean and inner-product similarity, and HNSW and IVFFlat indexes. It lets you store embeddings next to your normal rows and find the nearest neighbours to a query vector with ordinary SQL, which is the core operation behind semantic search and RAG.

Is pgvector a vector database?

It makes PostgreSQL function as one. You get vector storage, approximate nearest-neighbour indexes and distance operators inside a general-purpose relational database, with transactions, backups, replication and SQL filtering included. Dedicated vector databases add distributed scale and specialised features, but for collections up to a few million vectors pgvector is usually sufficient.

Should I use HNSW or IVFFlat in pgvector?

HNSW is the usual default: better recall and faster queries, at the cost of a slower build and more memory. IVFFlat builds faster and uses less memory but needs representative data loaded before the index is created and generally gives lower recall at the same speed. Start with HNSW unless build time or memory on a very large table is the constraint.

How many dimensions does pgvector support?

The vector type can hold up to 16,000 dimensions, but an index on the vector type supports up to 2,000 dimensions. The halfvec type (16-bit floats) raises the indexable limit to 4,000. Most text embedding models produce between 256 and 3,072 dimensions, so very wide embeddings may need halfvec or a model with a smaller output.

Does Ethora use pgvector?

Yes. Ethora's RAG knowledge base stores 256-dimension embeddings in Postgres with pgvector, and agents query it by similarity before answering. In the official Ollama example the embedding model is set with the AI_EMBEDDING_MODEL variable and must return 256-dimension vectors. In a self-hosted deployment the database sits inside the same perimeter as the chat server.

Glossary

pgvector

Vector search inside the database you already run. A Postgres extension that stores embeddings next to your rows, indexes them with HNSW or IVFFlat, and lets a plain SQL query find the nearest neighbours.

General definition

pgvector is an open-source extension that turns PostgreSQL into a vector database. It adds a vector column type for storing embeddings, operators for the distances that similarity search uses, and index types that make nearest-neighbour queries fast on millions of rows. A query looks like any other SQL: order by the distance between a stored vector and the query vector, limit to the top results, and join or filter on the other columns in the same statement.

Distances: cosine distance (<=>), Euclidean or L2 (<->) and inner product (<#>), plus L1 and binary distances in newer releases; cosine is the usual choice for text embeddings
Indexes: HNSW (a graph index added in version 0.5.0, with better recall and query speed but slower to build and larger in memory) and IVFFlat (clusters the vectors, smaller and faster to build, needs data present before indexing)
Types: vector for 32-bit floats, halfvec for 16-bit, sparsevec for sparse vectors and bit for binary; an index on vector supports up to 2,000 dimensions
Availability: installed with one CREATE EXTENSION statement and offered on Amazon RDS and Aurora, Google Cloud SQL, Azure Database for PostgreSQL, Supabase, Neon and most other managed Postgres services

Teams prefer it to a separate vector database for unglamorous, good reasons. The embeddings live in the same database as the users, documents and permissions they belong to, so access control, transactions, backups, replication and point-in-time recovery already cover them. A retrieval query can filter by tenant, date or role in the same SQL, which a standalone vector store does with less flexible metadata filters. There is one fewer system to run, secure and audit, which matters in regulated environments where every data store needs a named owner and a retention policy. And the operational knowledge already exists: most teams run Postgres, and nobody runs a vector database by accident.

The limits appear at scale. pgvector runs on a single node, so very large collections (hundreds of millions of vectors) or very high query rates push teams towards sharding or a dedicated engine. HNSW index builds for large tables need memory and time, and the index has to fit in RAM for good latency. Combining a vector index with selective filters can return fewer results than requested, which newer releases address with iterative scans. Dimensions above the index limit need halfvec or a smaller embedding model. For the common case, a knowledge base of thousands to a few million chunks behind a RAG pipeline or semantic search feature, it is usually the right default.

In the Ethora ecosystem

Ethora’s RAG store is Postgres with pgvector. When an agent built with the AI SDK ingests knowledge, from the website crawler or uploaded documents, the chunks are embedded as 256-dimension vectors and written to pgvector, and every question the agent answers starts with a similarity query against that table. The width is fixed, so the embedding model behind the deployment’s OpenAI-compatible endpoint has to return 256-dimension vectors, which the official Ollama example configures with the AI_EMBEDDING_MODEL variable.

The choice follows the reasoning above. A chat platform for regulated industries already runs databases with retention, backup and access rules, and a self-hosted customer can place the pgvector database inside the same perimeter as the chat server and the self-hosted model, so knowledge base content never leaves it. At 256 dimensions the vectors are small and sit comfortably within the index limits, and a per-agent knowledge base of thousands of chunks is well inside the range where pgvector is fast on ordinary hardware.

pgvector

General definition

In the Ethora ecosystem

Build AI agents on your own stack

Talk to our team

Pick a time that works for you