Which option fits a team that already runs a database or search cluster
If your team already runs PostgreSQL, pgvector is usually the shortest path to vector search, because vectors sit in the same database as your relational data, under the same backups, roles and upgrade cycle. It is a PostgreSQL extension under the PostgreSQL License, it supports exact search by default, and its HNSW and IVFFlat indexes apply to vector columns of up to 2,000 dimensions. Choose it when your retrieval is tied to rows you already manage and the embedding size fits that index limit. Confirm which PostgreSQL major version your platform runs, since the pgvector README states support for PostgreSQL 13 and later.
If your estate is built around keyword search and you want vectors in the same engine, OpenSearch k-NN is the Apache-2.0 option. All software in the OpenSearch project is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition, so the license question is simpler than with Elastic. The knn_vector field supports HNSW, IVF, flat and disk_ann methods through the Faiss, Lucene and plugin-based engines. Check which engine and method your target version supports, and whether the Security plugin's SAML, OpenID Connect or LDAP settings already match your identity provider.
If you already run Elasticsearch, dense_vector keeps vectors inside an estate your team knows, but the conditions are commercial. The default distribution is under the Elastic License 2.0, and some security and alerting features sit in paid tiers. Single sign-on and field- or document-level security are not part of the free Basic tier, and Platinum is no longer offered to new customers. Confirm your current subscription tier and the dimension ceiling of 4,096 before you commit. The right answer depends on your existing stack, your scale and the tiers you already pay for, so test your own embeddings and filters before deciding.
Which scenario points to which option
This table maps common starting points to the option that fits best, with the supplied fact behind each choice. Read it as a first filter: if your scenario matches a row, check the reason and then confirm the listed condition in your own environment before deciding.
| Scenario | Best fit | Reason and condition |
|---|---|---|
| Existing PostgreSQL application with modest vector volume | pgvector | Runs inside PostgreSQL, so vectors sit beside relational data. Indexes vector columns up to 2,000 dimensions and supports exact search by default. Confirm your embedding size fits that limit. |
| Existing OpenSearch log and search estate | OpenSearch k-NN | knn_vector fields use HNSW, IVF, flat or disk_ann methods with Faiss, Lucene or JVector engines. Keeps vectors in the cluster you already operate. Confirm the engine and method suit your recall and memory targets. |
| Existing Elasticsearch estate on a current release | Elasticsearch dense_vector | Dense vectors support cosine, dot product, L2 norm and max inner product, with a 4,096 dimension ceiling. Confirm your license tier, since security features such as field-level security sit in paid tiers. |
| Need for hybrid keyword and vector search in one query | Elasticsearch or OpenSearch | Both are full-text search engines, so keyword ranking and vector similarity live in one index. pgvector can combine SQL filters with vector ordering, but full-text ranking depends on PostgreSQL features you must design yourself. |
| Strict Apache-2.0 requirement | pgvector or OpenSearch | pgvector uses the PostgreSQL License, and OpenSearch project software is Apache-2.0. Elasticsearch's default distribution is Elastic License 2.0, so it does not meet this rule without the AGPLv3 option. Confirm the exact terms with your legal team. |
| Greenfield build with heavy filtering and large vector counts | Dedicated vector store, evaluated separately | pgvector filters after the index scan and needs iterative scans to recover results. Test filtered recall on your own data before committing to any of the three options here. |
| Greenfield build with no existing search or database platform | Decide on operating skill first | Choose the store your team can patch, back up and scale. Adding a search cluster or a dedicated store adds components, so ask what each one needs to run in your infrastructure. |
What the license and paid tiers mean for your deployment
The license decides whether you can run these engines without a paid contract, so check it before you compare features. pgvector is released under the PostgreSQL License, a permissive license with no paid edition attached to the extension. OpenSearch is released under the Apache License, Version 2.0, and its FAQ does not describe any paid edition, so the k-NN features sit in the same open distribution as the rest of the search stack. Elasticsearch is different: its default distribution is under the Elastic License 2.0, and Elastic also offers AGPLv3 and SSPL 1.0 options. Elastic states that ELv2 and SSPL are not OSI-approved open source licenses, so if your policy requires OSI-approved licensing, confirm that you will use the AGPLv3 option and not the default.
Security controls are where Elasticsearch tiers matter most for a regulated team. Elastic moved TLS, the file and native user realms and role-based access control into the free Basic tier with versions 6.8.0 and 7.1.0 in May 2019. Single sign-on (SAML, OpenID Connect, Kerberos, JWT), Active Directory and LDAP authentication, and field- and document-level security remain in paid tiers. Elastic also states that the Platinum tier is no longer available to new customers and points them to Elastic Cloud, so a Platinum-based design may not be purchasable. Map each control your architecture needs to a tier, then ask the vendor which tier provides it and whether that tier is still sold to you. OpenSearch Security, by contrast, lists SAML, OpenID Connect, LDAP and document-level security in its documentation, which you should verify against the version you deploy.
Treat these terms as a snapshot. Confirm current license terms, tier availability and feature gating in writing with each vendor, and have your counsel review the license text for the exact distribution you plan to run, including any enterprise directories or add-on modules. Ask for the license of each component in the stack, because a pgvector deployment inside a PostgreSQL service may involve a different contract than a standalone search cluster. Record the answers with the date you received them, since terms in this category change.
Each option in brief, with its license and release status
Vector search sits in three different places: a PostgreSQL extension, search engines that already index your text, and dedicated vector stores. The cards below give each option's license, latest supplied release and the condition under which it is the right pick, with Qdrant and Milvus shown as the dedicated-store comparison point.
pgvector in PostgreSQL
pgvector is a PostgreSQL extension under the PostgreSQL License, with version 0.8.7 released on October 1, 2026. It keeps vectors in the same database as your relational data, so backups, roles and transactions stay in one place. It is the right choice when your team already runs PostgreSQL and the corpus is modest enough for exact or HNSW search. Check how filtered queries perform on your own data, since filters apply after the index scan.
OpenSearch k-NN
OpenSearch k-NN is part of the Apache License, Version 2.0 OpenSearch project, with no paid edition described in its FAQ. Its knn_vector fields support HNSW, IVF, flat and disk_ann methods through several engines. It fits teams that already run OpenSearch for logs or full-text search and want vectors next to that text. Confirm which engine and method you need, and plan upgrades around the roughly eight-week minor release cadence.
Elasticsearch dense_vector
The dense_vector field in Elasticsearch is available under the Elastic License 2.0 as the default distribution, with AGPLv3 as an OSI-approved option added in 2024. Dense vectors are capped at 4096 dimensions and support cosine, dot product, L2 and max inner product similarity. It suits organizations already standardized on Elastic for search and security data. Confirm which subscription tier you need, because security features such as field-level security sit in paid tiers.
Qdrant as a dedicated store
Qdrant is an Apache-2.0 licensed vector database written in Rust, with horizontal scaling through sharding and replication. It offers JSON payload filtering, dense, sparse and hybrid search, and built-in quantization. It is worth considering when vector workloads grow large enough to need their own scaling and replication, or when filtered search is central to the product. Compare its operating effort with your existing database team's capacity before adopting a second stateful system.
Milvus as a dedicated store
Milvus is an Apache-2.0 licensed distributed vector database under the LF AI and Data Foundation, with two maintained release lines. Its architecture separates stateless proxies, coordinators and worker nodes, and depends on etcd for metadata and object storage such as MinIO or S3. It suits very large collections that need independent scaling of storage and compute. Plan for the extra components, since the architecture has more moving parts than a PostgreSQL extension.
How filtering and scaling change the answer at larger volumes
Filtering is where pgvector needs the most testing. Its HNSW and IVFFlat indexes find approximate candidates, and filters are applied after that index scan. A selective WHERE clause can therefore return fewer rows than the query asked for. Iterative index scans, in strict or relaxed ordering modes, fetch more candidates when filters remove too many, but each extra pass adds work to the query. Run your real filter combinations against exact search on data at the size you expect, and check recall for rare tenants or narrow date ranges. Also remember that vectors share the instance with your transactional tables, so scans, index builds and backups compete for CPU, memory and I/O. Confirm your PostgreSQL major version plan with your DBA, since the PostgreSQL versioning policy sets the support window for each release.
Node roles decide how OpenSearch and Elasticsearch scale vector workloads. Elasticsearch separates work into master-eligible, data, ingest, machine learning, transform and coordinating-only roles, and its node roles documentation says a highly available cluster needs at least three master-eligible nodes. Dedicated data nodes can be sized for vector memory and disk, while coordinating-only nodes absorb query fan-out. Three master-eligible nodes is a minimum for availability and says nothing about capacity, so model your vector memory and replica count separately. Confirm the equivalent cluster guidance in the OpenSearch documentation before you size the cluster, and confirm which features your Elastic subscription tier includes. The extra nodes, storage and upgrades recur every month of operation, and they are the main cost you add when vector search moves off a database you already run.
A dedicated store earns its cost when vector search becomes a workload of its own. Typical signals are filters that must stay accurate at scale, vector search that has to grow independently of your relational database, or a need for sharding and replication designed around vectors. Qdrant documents horizontal scaling with sharding and replication, payload filtering on vectors and built-in quantization, which its README says can cut RAM usage by up to 97%. Milvus adds more moving parts: stateless proxies, coordinator and worker nodes, etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log built on Woodpecker, Kafka or Pulsar, as described in the Milvus architecture overview. That design can scale out, but it gives you more services to patch, back up and monitor. Before you decide, load your own data volume and filter selectivity into each option, and ask your implementation partner for a written operating runbook covering both.
What each option asks of your operations team
pgvector runs as an extension inside a PostgreSQL cluster you already operate, so the work is mostly the database team's existing routine. Vectors sit in the same database as relational data, which means backups, replication, role management and patching follow the PostgreSQL practices you already have. The upgrade rhythm is set by PostgreSQL itself, not by a separate vector product.
- Installation path: Enable the extension in an existing PostgreSQL instance; the extension itself is released under the PostgreSQL License and the README states support for PostgreSQL 13 and later.
- Upgrade cadence: PostgreSQL ships a new major version about once a year, with five years of support for each, so plan major upgrades on that schedule and retest the extension version against each one.
- Extension versioning: Track the pgvector release line separately from the PostgreSQL major version; version 0.8.7 was released on October 1, 2026, per its CHANGELOG.
- Security: Access control, encryption and auditing come from the PostgreSQL configuration you already maintain, so confirm how your current role model and audit settings apply to vector tables.
- Scaling limits: Confirm index behavior for your dimension count, since indexing is supported up to 2,000 dimensions, and check your own memory and replication headroom for HNSW indexes.
Before committing, confirm with your DBA team which PostgreSQL major version you will run, how long it remains supported, and whether your backup and replication tooling handles the extension's index types.
OpenSearch is a standalone search cluster with its own installation, upgrade and security surface, so it adds a new platform to operate rather than extending an existing one. The project is Apache-2.0 licensed across all of its software, and its docs cover several install paths, including Docker, Helm, the OpenSearch Kubernetes Operator, tarballs, RPM and Debian packages, and an Ansible playbook. Choose the path that matches how your team already builds and patches infrastructure.
- Release rhythm: OpenSearch targets a new minor version about every eight weeks; 3.9.0 was released on September 29, 2026 and 3.8.0 on August 4, 2026.
- Maintenance windows: A version stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and maintenance receives bug fixes and security patches but no new features.
- Security plugin: The Security plugin provides SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JWT authentication, plus role-based access control, document- and field-level security, field masking, audit logs and TLS.
- Upgrade path: Indices from Elasticsearch 6.0 through 7.10 can be used, and rolling upgrades are supported from those versions; use the migration guides for later moves.
- Governance: The OpenSearch Software Foundation is a Linux Foundation project, but it does not oversee technical direction, so confirm your own support contract and patch channel.
Confirm which OpenSearch line you will standardize on, who owns the security plugin configuration, and how often your team can absorb a minor upgrade every eight weeks.
Elasticsearch is a distributed cluster with defined node roles and a licensing model that changes what you can run without a subscription. Its default distribution is under the Elastic License 2.0, with SSPL and AGPLv3 as the other source options, and the AGPLv3 option was added to provide an OSI-approved choice. Plan the cluster shape first, because a highly available cluster needs at least three master-eligible nodes.
- Node roles: Master-eligible, data (with hot, warm, cold and frozen tiers), ingest, machine learning, transform, remote cluster client and coordinating-only roles each need placement decisions.
- Release and end of maintenance: The 9.x core stack reaches end of maintenance on October 15, 2027 and 8.x on January 15, 2027, with 8.x support ending July 15, 2027, per Elastic's end-of-life page.
- Security tiers: TLS, native realms and role-based access control are free in the Basic tier, while single sign-on, Active Directory and LDAP, and field- or document-level security sit in paid tiers.
- Kubernetes: Elastic Cloud on Kubernetes is offered in Basic and Enterprise tiers as a self-managed product, which changes the operator choice for Kubernetes shops.
- Subscription status: The Platinum tier is no longer offered to new customers, so confirm which tier your required features map to today.
Confirm with Elastic which subscription tier covers your identity and field-level requirements, and build your upgrade calendar around the end-of-maintenance dates for the release line you select.
How to choose and pilot the option that fits your stack
This sequence tells you whether pgvector, OpenSearch k-NN or Elasticsearch dense_vector can carry your workload inside a cluster you already run, and gives you measured evidence before you commit to a dedicated vector store.
Inventory your existing databases and search clusters
Platform engineering and the owners of each data store list every PostgreSQL instance, OpenSearch cluster and Elasticsearch cluster in scope, along with their versions, hosting location, backup routine and who operates them. Confirm the exact versions in your environment, since pgvector support depends on your PostgreSQL major version and the vector dimension limits differ per product. The step is done when you have one table that shows where the vectors would live and which team would carry the operating load.
Define filter and recall requirements
Product owners and the application team write down the embedding dimensions, the expected record count, the queries that must return results, the metadata filters those queries combine with vector similarity, and the recall level the business will accept against an exact search baseline. Filters that narrow results heavily behave differently from light ones, so note the most selective combinations explicitly. The step closes with a short requirements sheet that the pilot can be measured against.
Check license and tier needs against security requirements
Security and compliance leads map each candidate to the controls your environment requires. For pgvector, the PostgreSQL License and the access controls of your PostgreSQL deployment apply. For OpenSearch, the Apache 2.0 license covers the project, and you should confirm whether the Security plugin features you need, such as document-level security, audit logs and your identity backend, are present in your chosen distribution. For Elasticsearch, check the Elastic License 2.0 or AGPLv3 options, and confirm which subscription tier provides single sign-on, field- or document-level security and the FIPS 140-3 mode your policy requires. Ask Elastic or your reseller for written confirmation of the tier. The output is a signed-off list of acceptable candidates.
Stand up a pilot with the candidate index type
The data platform team loads a representative sample of your embeddings, including the full range of metadata fields, into a non-production instance of the shortlisted option. For pgvector, pick between an exact search and an HNSW or IVFFlat index. For OpenSearch, pick a knn_vector method and engine. For Elasticsearch, configure dense_vector with the similarity measure your embeddings were trained for. Record the exact index settings, since they become your baseline. The step is complete when the pilot answers the requirement queries end to end.
Measure recall and filter behavior under load
Engineers run the requirement queries against the pilot and compare the approximate results with exact search results on the same data. Measure latency and recall for the most selective filters separately from unfiltered queries. For pgvector, check whether iterative index scans are needed when filters remove many candidates. Repeat the test with the write volume and concurrency you expect in production. The output is a table of recall and latency per query class, which shows whether the chosen index type meets the requirement sheet.
Run an operations check on the pilot
Operators test backup and restore, a version upgrade on a copy of the pilot, node or instance failure, and the monitoring you would rely on. Estimate the ongoing effort from what you observe, and ask any implementation partner for a written scope that lists these tasks as deliverables. The step is done when the operations owner signs off that the team can run the option without a new skill set.
Decide whether a dedicated store is needed
The architecture group compares the pilot results with the requirement sheet and the operations check. Keep vector search in the existing database or cluster if the recall, filter and operating results meet the requirements and the data stays within the product's dimension limits. Consider a dedicated vector store such as Qdrant or Milvus if the measured filter behavior, scale, or required replication and sharding model cannot be met on the current platform. Record the decision and the evidence behind it, so the next review starts from facts rather than memory.
Questions teams ask before adding vector search to an existing stack
What drives the cost and effort of each vector search option?
The biggest driver is what you already run. Adding pgvector to a PostgreSQL server you operate adds an extension, index build time and capacity planning, but no new cluster. OpenSearch and Elasticsearch add a search cluster with its own nodes, storage, upgrades and access controls, even when you only need vectors. Costs fall into three groups: infrastructure you pay for monthly, labor to install, tune and patch, and any paid license or support tier. Ask any partner or vendor for a quote that separates these groups, states which nodes or replicas are included, and names the upgrade and backup responsibilities. The licenses are not the only cost, since the same vector workload can need very different hardware depending on dimensions, index type and the amount of data kept in memory.
Can pgvector run beside an existing PostgreSQL workload?
Yes, in many cases, because pgvector is an extension that runs inside PostgreSQL and keeps vectors in the same database as your relational data. The PostgreSQL License covers the extension. Before you add it, confirm that your server runs PostgreSQL 13 or later, as the pgvector README states. Then test the load. Approximate HNSW or IVFFlat indexes consume memory and build time, and vector queries compete with transactional traffic for CPU and I/O. Filtering also matters: with approximate indexes, filters apply after the index scan, and iterative index scans can fetch more rows when filters remove too many results. Plan a staging test with your real filters and row counts before you commit.
When is OpenSearch or Elasticsearch the better fit?
Choose them when you already run full-text search, log analytics or a search cluster with users and dashboards, and vector search is an added feature on that cluster. OpenSearch's knn_vector fields support HNSW, IVF, flat and disk_ann methods through several engines, and OpenSearch is distributed under the Apache License, Version 2.0. Elasticsearch dense_vector fields cap at 4096 dimensions and offer several similarity functions. Confirm that your embedding size and similarity method fit those limits. If your team already runs one of these clusters, the operating knowledge and access controls may outweigh the extra cost of a separate database.
Do SSO and field-level security require paid tiers?
It depends on the product and the feature. For Elasticsearch, Elastic's announcement states that TLS, the file and native user realms and role-based access control became free in the Basic tier, while single sign-on, Active Directory and LDAP authentication and field- or document-level security remained in paid tiers. Elastic's subscription page lists SSO and field-level security among its security features, so check the current tier table before you design around them. For OpenSearch, the Security plugin documents SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JWT authentication, plus document-level and field-level security, and the OpenSearch FAQ does not describe any paid edition. Confirm these features against the version you plan to deploy. For pgvector, access control comes from PostgreSQL roles and grants, which you configure in the database itself.
What does the work need from our internal team?
Plan for database or search administration skills that already exist in your organization. With pgvector, the team needs PostgreSQL administration, index tuning, backup and major version upgrades. PostgreSQL ships a major version about once a year, with five years of support for each, so budget time for regular upgrades. With OpenSearch or Elasticsearch, the team also needs cluster management: node roles, shard sizing, snapshots, security configuration and rolling upgrades. Elasticsearch documentation says a highly available cluster needs at least three master-eligible nodes. Ask your team to name an owner for each layer, and confirm which tasks the owner can perform without an outside partner.
Is an outside partner worth it for this work?
A partner is most useful when the work is fixed in scope and your team lacks time or specific experience. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. To scope it, bring your data volumes, vector dimensions, expected query load, identity provider, retention requirements and the platform you already run. Ask the partner to state what is excluded, who holds the credentials and how the work will be handed over.
What to confirm with vendors and your own environment before committing
The facts on this page settle the architecture and the published license terms, but several decisions still depend on details you must confirm. Start with licensing and tier entitlements. Elastic's licensing FAQ and Elastic subscriptions describe which security and machine learning features sit in each tier, and Elastic states that the Platinum tier is no longer open to new customers, so ask Elastic in writing which tier covers the exact features you need, such as field- and document-level security or single sign-on. For OpenSearch, confirm with the project that the security and vector features you depend on are in the Apache 2.0 distribution you deploy, and check the OpenSearch releases page for the maintenance status of your exact minor version. Support windows differ by product, so ask for the end-of-maintenance date of your version, not the major line.
Next, test the parts the facts cannot settle. Recall and latency depend on your embeddings, dimension count, filter selectivity and index settings, so build a small labelled query set from your own documents and measure recall against exact search on the same data. For pgvector, check that filtered queries still return enough rows with the iterative scan settings described in its README. For OpenSearch and Elasticsearch, run the same test against the knn_vector or dense_vector mapping you intend to use, and record the similarity function and index method each run uses. Rerun the test after each planned version upgrade, because index behavior can change between releases.
Then confirm operations that are easy to overlook. Ask how vector indexes are included in backups and whether a restore has been verified for each store, including the time to rebuild approximate indexes after a restore. In PostgreSQL, vectors follow the normal backup path, but you must confirm the extension version is available on the restore target. For compliance, list the evidence your auditors need, such as access logs, encryption settings and change records, and confirm with each vendor which controls the product can produce that evidence. DeployOpen can prepare configurations and evidence for that review, but independent auditors issue any assessment result.
How DeployOpen scopes and delivers a vector search implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For vector search, that means we start from the database or search cluster you already run, agree the scope in writing, and hand over a system your team can operate.
How we scope
- We confirm which platform you already run and what version and license posture it has today.
- We document the embedding dimensions, record counts, filter fields and query patterns the written scope covers.
- We agree deliverables and timelines in writing before any work starts, and the quote follows from that scope.
How we build
- We install and configure the chosen engine inside your environment, with index method and distance settings recorded.
- We test filtered and unfiltered queries, recall against exact search, and resource use at the sizes in scope.
- We wire authentication, role-based access and audit logging to your existing identity and logging setup.
How we hand over
- You receive configuration, index design notes, runbooks for backup, restore and upgrades, and test results.
- We walk your operators through routine tasks so the team can run indexing, reindexing and version upgrades alone.
- We record the conditions under which a dedicated vector store would be worth evaluating as data grows.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover version upgrades, security patch review and re-testing after schema or index changes.
- Support scope and response expectations are set in the written agreement, so confirm them during quoting.
