GUIDE

What is a vector database?

A vector database is a database that stores embeddings, the lists of numbers a machine learning model produces to represent the meaning of text, images, or audio, and finds the stored items closest to a query vector using approximate nearest-neighbor indexes. Powabase keeps vectors in pgvector inside each project's own Postgres, with retrieval built in.

Last reviewed: September 24, 2026

How does a vector database work?

First, an embedding model turns each piece of content, such as a paragraph, product description, or image, into a vector with hundreds or thousands of dimensions. Content with similar meaning lands close together in that space, so "cancel my subscription" sits near "how do I stop billing" even though they share no words. The database stores each vector next to an ID and metadata. At query time you embed the question with the same model and ask for the k nearest vectors by a distance metric, usually cosine distance, inner product, or Euclidean (L2) distance. Comparing the query against every row is exact but slow at scale, so vector databases build approximate nearest-neighbor (ANN) indexes. The two most common are HNSW, a layered graph that is fast and accurate but memory-hungry, and IVF, which clusters vectors and searches only the nearest clusters. Both trade a little recall for a large speedup. Filtering by metadata, such as tenant, date, or document type, is the other half of the job, and it is where many implementations differ.

What is a vector database used for?

The main use today is retrieval-augmented generation (RAG): find the passages most relevant to a question and hand them to a language model so it answers from your data instead of its training set. The same nearest-neighbor query also powers semantic search over docs or tickets, recommendations ("items like this one"), deduplication and near-duplicate detection, image and multimodal search, clustering and classification, and long-term memory for agents, where past conversations and facts are embedded and recalled when relevant. In most of these, vector similarity alone isn't enough. Exact terms such as product codes, names, and error messages are better matched by keyword search, which is why production retrieval usually combines both (hybrid search) and then reorders the top results with a reranking model.

  • RAG: grounding LLM answers in your documents
  • Semantic search over docs, tickets, or products
  • Recommendations and similar-item lookup
  • Agent memory recalled by meaning
  • Image and multimodal search
  • Deduplication and clustering

What types of vector databases are there?

There are two broad categories. Dedicated vector databases are built around vector search. Pinecone is a managed service with serverless indexes, sparse and dense vectors for hybrid search, and optional integrated embedding (see Powabase vs Pinecone). Weaviate (BSD-3-Clause), Qdrant (Apache-2.0, written in Rust), and Milvus (Apache-2.0, an LF AI & Data project) are open source and available both self-hosted and as managed clouds. The second category adds vector search to a database you already run. pgvector is the open-source Postgres extension: a vector column type, HNSW and IVFFlat indexes, and cosine, inner product, L2, and other distances, with Postgres transactions, joins, and point-in-time recovery. Other general-purpose databases, including Firestore, MongoDB Atlas, and Elasticsearch, now offer vector search too. A third option is to not run a vector store directly at all and use a platform that manages retrieval end to end on top of one of these.

Dedicated vector database vs pgvector

A dedicated vector database is built for one job and it scales that job well. Its engine, sharding, and memory handling are tuned for very large collections and high query rates, and managed options take indexing and capacity planning off your plate. The cost is a second system. Your app data lives in one database and its embeddings in another, so every insert, update, delete, and permission change has to reach both, and the two can drift apart. pgvector keeps embeddings in the same Postgres as the rows they describe. One transaction writes both. A single query can join vectors to users, filter by tenant with Row Level Security, and combine the similarity score with SQL conditions. Backups, access control, and monitoring are the ones you already have. pgvector does have limits. Indexed vector columns top out at 2,000 dimensions (4,000 with halfvec), HNSW indexes want memory, and approximate indexes apply filters after the scan, which pgvector 0.8.0 improved with iterative index scans. For most apps, up to many millions of vectors, pgvector is enough and simpler to run.

Do you need a separate vector database for RAG?

Usually not. The vector store is one part of a RAG system, and rarely the hard one. Retrieval quality depends more on how documents are extracted (tables, scans, and layout), how they are chunked, whether you combine vector and keyword search, and whether you rerank the candidates. A separate vector database answers none of those questions and adds a sync problem on top: when a document is edited, deleted, or reshared, the change has to reach the vector store before the next query. Keeping embeddings in Postgres next to documents and permissions avoids that class of bug. Reach for a dedicated vector database when your collection is in the hundreds of millions or billions of vectors, when query volume would overwhelm your primary database, or when you need features only a specialized engine has. Otherwise, start with pgvector, measure recall and latency on your own data, and move only if the numbers tell you to. If you'd rather not run retrieval as its own service, use a backend as a service built for AI apps that keeps it on the same Postgres.

How Powabase does it

How Powabase does it

Powabase makes the vector database part of the backend instead of another service. Every project runs its own Postgres instance with pgvector installed, and knowledge bases index into it. Upload a file and Powabase extracts, chunks, embeds, and indexes it, then serves retrieval over the same REST API as the rest of your app. When you need your own schema, create a vector column on any table and query it with SQL or PostgREST.

  • Embeddings live in pgvector next to your app data, with HNSW indexes and Row Level Security
  • Extraction for PDFs, Office files, images (with OCR), and URLs, then chunking and embedding on upload
  • Five indexing strategies, including ChunkEmbed, PageIndex, and GraphIndex
  • Vector, full-text (BM25), hybrid (RRF fusion), and tree search, with optional cross-encoder reranking
  • Agents that search knowledge bases as a tool, with citations streamed back over SSE
  • Embedding models from multiple providers; bring your own keys

Dedicated vector database vs pgvector vs Powabase

  • Examples

    Dedicated vector database:
    Pinecone, Weaviate, Qdrant, Milvus
    pgvector on your own Postgres:
    pgvector extension
    Powabase:
    pgvector in each project's Postgres

  • Where app data lives

    Dedicated vector database:
    A separate database
    pgvector on your own Postgres:
    Same database
    Powabase:
    Same database

  • Keeping vectors in sync

    Dedicated vector database:
    Your pipeline, across two systems
    pgvector on your own Postgres:
    Same transaction
    Powabase:
    Managed on upload

  • Document extraction and chunking

    Dedicated vector database:
    Build your own (some offer integrated embedding)
    pgvector on your own Postgres:
    Build your own
    Powabase:
    Built in

  • Hybrid search and reranking

    Dedicated vector database:
    Varies by product
    pgvector on your own Postgres:
    Build it in SQL; reranker is yours
    Powabase:
    Built in

  • Access control

    Dedicated vector database:
    Namespaces, collections, or API keys
    pgvector on your own Postgres:
    Postgres roles and Row Level Security
    Powabase:
    Postgres roles and Row Level Security

  • Best fit

    Dedicated vector database:
    Hundreds of millions of vectors and up, very high query rates
    pgvector on your own Postgres:
    Apps that already run Postgres
    Powabase:
    AI apps that want RAG and agents on their own backend

FAQ

Questions.

A vector database stores numeric representations of content (embeddings) and finds the items whose meaning is closest to a query. It lets you search by meaning rather than exact words, which is what RAG, semantic search, and recommendations need.

With the pgvector extension, yes. pgvector adds a vector column type, HNSW and IVFFlat indexes, and cosine, inner product, and L2 distance to Postgres, so one database holds both your app data and its embeddings. Every Powabase project ships with pgvector installed.

It depends on scale. For most apps, pgvector in the Postgres you already use is the simplest good choice. At hundreds of millions of vectors or very high query rates, dedicated engines such as Pinecone, Qdrant, Weaviate, or Milvus are built for that load.

For most workloads, yes. HNSW indexes give fast approximate search over millions of vectors, and pgvector 0.8.0 added iterative index scans for filtered queries. Keep indexed vectors at 2,000 dimensions or fewer, give the index enough memory, and measure recall on your own data.

You need vector search, not necessarily a separate vector database. pgvector in Postgres covers most RAG apps and avoids syncing two systems. Powabase goes further: it extracts, chunks, embeds, and indexes documents on upload and serves hybrid search with reranking.

A vector index, such as HNSW or IVF, is the data structure that makes nearest-neighbor search fast. A vector database wraps indexes with storage, updates, metadata filtering, access control, backups, and an API. pgvector gives Postgres the index and relies on Postgres for the rest.

For most RAG and semantic search apps, yes. Powabase stores embeddings in pgvector in each project's own Postgres, next to your app data, and adds extraction, hybrid search, reranking, and agents on top, so there's no separate vector database to run or keep in sync.

Docs

Sources

  1. https://www.pinecone.io/learn/vector-database/: Definition of a vector database: indexes and stores embeddings for similarity search, with CRUD, metadata filtering, and scaling.
  2. https://docs.pinecone.io/guides/index-data/indexing-overview: Pinecone dense and sparse vectors, hybrid search, and integrated embedding.
  3. https://github.com/pgvector/pgvector: pgvector index types, distance functions, dimension limits, filtering after approximate index scans, iterative scans in 0.8.0, ACID, PITR, and joins.
  4. https://github.com/weaviate/weaviate: Weaviate is an open-source vector database under BSD-3-Clause.
  5. https://github.com/qdrant/qdrant: Qdrant is an open-source vector database written in Rust under Apache-2.0, with a managed cloud.
  6. https://milvus.io/docs/overview.md: Milvus is an open-source vector database under Apache-2.0, an LF AI & Data Foundation project.
  7. https://firebase.google.com/docs/firestore/vector-search: Firestore offers vector search.
  8. https://www.mongodb.com/docs/vector-search/: MongoDB offers vector search.
  9. https://www.elastic.co/docs/solutions/search/vector/knn: Elasticsearch offers kNN vector search with HNSW.
  10. https://supabase.com/docs/guides/ai: pgvector-based semantic, keyword, and hybrid search in Postgres.