PGVector is a PostgreSQL extension that adds vector similarity search, enabling AI-powered features like semantic search, RAG, and recommendation engines directly inside your existing Postgres database.
.svg){kind=logo}
PGVector is an open-source PostgreSQL extension that enables vector similarity search directly inside your Postgres database. Instead of spinning up a separate vector database like Pinecone or Weaviate, PGVector lets you store embeddings alongside your relational data and run similarity queries using familiar SQL syntax.
The extension supports exact and approximate nearest-neighbor search using IVFFlat and HNSW indexes. It handles vectors up to 2,000 dimensions, which covers most modern embedding models including OpenAI's text-embedding-3-small and Cohere's embed-v3. Companies like Supabase have built their entire vector search offering on top of PGVector, and it's the default vector store for many LangChain and LlamaIndex deployments.
The real appeal is operational simplicity. If you already run Postgres (and most teams do), PGVector means no new infrastructure, no new backup strategy, no new monitoring stack. Your vectors live in the same ACID-compliant database as your application data, with the same connection pooling, replication, and failover you already trust.
You need PGVector expertise when your team is building AI features on top of an existing PostgreSQL infrastructure. Common triggers include:
If your vector search needs exceed 10-50 million vectors or require sub-millisecond latency at massive scale, a dedicated vector database like Pinecone or Qdrant might be a better fit. But for the vast majority of production workloads, PGVector handles the job well.
A strong PGVector developer isn't just someone who can install an extension. Look for these markers:
Strong answer: HNSW provides better recall with less tuning and supports concurrent inserts without rebuilding. IVFFlat is faster to build and uses less memory but requires periodic reindexing as data changes. HNSW is the default choice for most production workloads; IVFFlat makes sense for very large, relatively static datasets where build time matters.
Look for: a migration strategy involving batch re-embedding, dual-column storage during transition, and validation that search quality is maintained. Bonus if they mention versioning embeddings or A/B testing retrieval quality.
Expect: checking EXPLAIN ANALYZE output, verifying the index is being used, adjusting ef_search or probes parameters, checking if the dataset has outgrown the index configuration, and potentially examining shared_buffers and work_mem settings.
Strong candidates will discuss pre-filtering vs. post-filtering tradeoffs, partial indexes on commonly filtered columns, and the performance implications of combining WHERE clauses with ORDER BY vector distance.
Look for: combining PGVector cosine similarity with Postgres ts_vector full-text search, using reciprocal rank fusion or weighted scoring, and chunking strategies for document ingestion.
PGVector expertise sits at the intersection of database engineering and AI/ML, which commands a premium over general Postgres roles.
These rates reflect the current scarcity of engineers who combine deep Postgres expertise with AI/ML pipeline experience. As PGVector adoption grows and more engineers gain experience, LatAm rates may compress slightly, but the cost advantage remains substantial.
Latin America has a strong PostgreSQL community — Postgres has been the database of choice for many LatAm startups and tech companies for over a decade. This means the region has a deep bench of Postgres experts who are now adding vector search to their toolkit.
South specializes in connecting US companies with vetted Latin American developers. Here's how the process works for PGVector roles:
If your DBA has experience with embeddings and AI pipelines, they can likely manage PGVector. But if you're building a production RAG system or semantic search feature, you want someone who understands both the database and ML sides.
PGVector handles millions of vectors well with proper indexing. For datasets beyond 50 million vectors or requirements for sub-10ms latency, dedicated solutions like Pinecone or Qdrant may be better. For most applications, PGVector is more than sufficient.
Yes. PGVector is supported on AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL, Supabase, and Neon. Experienced developers know the nuances of each platform's PGVector implementation.
A senior Postgres developer with AI/ML exposure can be productive with PGVector within 1-2 weeks. Someone new to both Postgres and embeddings will need 4-6 weeks to get up to speed on production workloads.
Yes. Companies like Supabase, Instacart, and numerous YC startups run PGVector in production. It's battle-tested and actively maintained with frequent releases.
