{"title":"Elasticsearch vs pgvector","slug":"elasticsearch-vs-pgvector","tools":[{"name":"Elasticsearch","slug":"elasticsearch","category":"vectordb","type":"hybrid","website":"https://www.elastic.co/elasticsearch","pricing":"freemium","pricing_tiers":["Free (self-hosted, Elastic License v2 / SSPL)","Elastic Cloud Hosted $99+/mo (Standard, Gold, Platinum, Enterprise)","Elasticsearch Serverless (pay per use)"],"open_source":true,"self_hosted":true,"sdk_languages":["python","javascript","typescript","go","java","ruby","php","csharp","rust"],"frameworks":["langchain","llamaindex","vercel-ai","haystack"],"agent_features":{"hybrid_search":true,"metadata_filtering":true,"multi_tenancy":true,"managed_embeddings":true,"mcp_server":true,"serverless":true},"compliance":["soc2","hipaa","gdpr","pci-dss","iso27001"],"best_for":"Hybrid search at scale on top of mature search infrastructure — combine BM25, ELSER sparse vectors, and dense vectors in one query","limitations":"Heavier and more memory-hungry than purpose-built vector engines; license is no longer pure Apache 2.0; vector-only workloads are overserved by Elasticsearch's full feature surface","verified_by":"editorial","last_verified":"2026-06-10","source_urls":{"docs":"https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html","pricing":"https://www.elastic.co/pricing","changelog":"https://www.elastic.co/docs/release-notes/elasticsearch"}},{"name":"pgvector","slug":"pgvector","category":"vectordb","type":"self-hosted","website":"https://github.com/pgvector/pgvector","pricing":"open-source","pricing_tiers":["Free (open-source PostgreSQL extension)","Available on managed Postgres: Supabase, Neon, RDS, Cloud SQL, Crunchy Bridge"],"open_source":true,"self_hosted":true,"sdk_languages":["python","javascript","typescript","go","java","ruby","rust","csharp","php"],"frameworks":["langchain","llamaindex","vercel-ai","haystack"],"agent_features":{"hybrid_search":true,"metadata_filtering":true,"multi_tenancy":false,"managed_embeddings":false,"mcp_server":false,"serverless":false},"compliance":["soc2","hipaa","gdpr","pci-dss"],"best_for":"Teams already running Postgres who want vector search without adding a new database — ACID, joins, and one operational story","limitations":"Slower at scale than purpose-built engines; no native multi-tenancy primitives beyond schemas; hybrid search and serverless depend on the host platform (Supabase, Neon, etc.), not pgvector itself","verified_by":"editorial","last_verified":"2026-06-10","source_urls":{"docs":"https://github.com/pgvector/pgvector#readme","changelog":"https://github.com/pgvector/pgvector/releases","ecosystem":"https://github.com/pgvector/pgvector#hosted-postgres"}}],"category":"vectordb","last_verified":"2026-06-10","body":"Elasticsearch and pgvector both add vector search to platforms you might already run. Elasticsearch is a heavyweight search engine; pgvector is a small extension on Postgres. The decision is whether your operational data is search-shaped or relational.\n\n## Where Elasticsearch wins\n\n* **Hybrid retrieval is the default, not an add-on.** Dense + ELSER sparse + BM25 with reciprocal rank fusion in a single query. pgvector + `tsvector` can do hybrid search, but you build the fusion yourself.\n\n* **`inference` API hosts embedding and reranker models in-cluster.** pgvector has no embedding pipeline of its own.\n\n* **Built for vector workloads at hundreds of millions of vectors.** Postgres with pgvector starts to feel the heat in that range, especially with concurrent writes.\n\n## Where pgvector wins\n\n* **One database, one backup, one auth story.** Vectors next to your users, documents, and audit logs. ACID transactions span everything.\n\n* **Row-level security enforces multi-tenancy in the database.** Elasticsearch isolates with document-level security or separate indices — both work, but neither matches Postgres RLS for declarative simplicity.\n\n* **No new vendor or operational surface.** Postgres is already in most stacks. Elasticsearch adds JVM tuning, cluster ops, and a separate observability story.\n\n## The agentic difference\n\nFor agents that already read and write Postgres data, pgvector keeps retrieval inside the same transactional and security boundary — RLS scopes vectors automatically, and joins enrich results without a second round trip. For agents whose retrieval quality depends on hybrid lexical+vector relevance across large or domain-heavy corpora, Elasticsearch's in-cluster inference and RRF deliver consistently better grounding than pgvector's hand-built hybrid.\n\n## When to pick which\n\n* **Pick Elasticsearch** when hybrid retrieval, in-cluster embeddings, or large-corpus scale are required.\n\n* **Pick pgvector** when the agent already lives in a Postgres-backed app and you want vectors inside the same database, backup, and auth model."}