Why hybrid search on self-hosted infrastructure needs a deliberate engine choice
Hybrid search needs a BM25 keyword index and a vector index that are queried together, and only some self-hosted engines provide both in one system. Enterprise teams searching policies, product catalogs or legal documents often find that pure vector search misses exact identifiers such as product codes, contract clause numbers and statute references, while keyword search misses paraphrased intent. When the query logs and indexed content must stay in your own infrastructure, the engine choice decides how much custom glue you will own. Weaviate and Milvus both offer BM25 keyword search combined with vector similarity in a native hybrid query, according to their public documentation. OpenSearch offers keyword search with its own vector capability, and PostgreSQL full-text search paired with pgvector is a workable option at smaller scale.
Treat the native support claims as a starting point, not a verdict. Confirm the exact version you plan to deploy, because hybrid query syntax, fusion methods and reranking options change between releases. Check how each engine combines the two result lists, since the fusion method and weighting are tuning decisions that affect relevance for exact-match queries. For Weaviate, the license file separates enterprise code in a wl directory from the BSD-3-Clause code, so confirm which features your deployment needs are covered by the open license. For Milvus, confirm the BM25 and sparse vector features against the release line you select, since two release lines are maintained.
Run a short proof of concept on your own corpus before committing. Build a test set of queries that mix exact identifiers with natural language, measure whether exact matches rank in the top results under each candidate, and record the query latency and memory use at your expected document count. Ask each candidate how filtering by access entitlements applies to both the keyword and vector legs of a hybrid query, because a filter that only applies to one leg can leak results. The engine that passes these checks on your data is usually a better choice than the one with the longest feature list.
Requirements that shape the hybrid search build
This table maps the data, access, logging and residency requirements that most affect a hybrid search design to what each one means for the build. Read each row as a question to answer before choosing an engine, since the answer often decides whether authorization must happen inside the search engine or can sit in front of it.
| Requirement | What it means for the build | What to confirm before choosing |
|---|---|---|
| Keyword recall for identifiers | Part numbers, case IDs, account codes and clause references often fail under pure vector similarity, so BM25 must run alongside dense retrieval and be tested on exact-match queries. | Ask each candidate engine to demonstrate exact-match recall on a sample of your identifiers, not only on natural language questions. |
| Per-document access control | If results must respect entitlements, filtering has to happen at query time inside the engine (document-level or tenant-level filters) rather than only after results are returned, or restricted text can leak into snippets and reranker inputs. | Confirm which engine applies permission filters before scoring, and whether a gateway in front can enforce them without exposing unfiltered candidates. |
| Entitlement sync and staleness | Access rules change faster than embeddings are rebuilt, so the build needs a process that updates permission metadata on indexed chunks when source permissions change. | Ask how permission changes propagate, how long a revoked user could still retrieve content, and how that window is tested. |
| Query and result audit logging | Where a high-risk AI system is involved, Article 12(1) of the EU AI Act requires the system to technically allow automatic recording of events over its lifetime. Logs should capture the query, filters applied, document identifiers returned and the user, which the search layer alone may not record by default. | Confirm which events the engine can log natively and which must come from the application or gateway. Check the EU AI Act Service Desk text for whether your system is in scope. |
| Log retention | Article 19(1) requires providers to keep automatically generated logs for at least six months unless other law provides otherwise. Retention for search logs therefore needs a defined period, storage location and deletion rule that does not remove query evidence early. | Agree the retention period with legal and compliance, and confirm that log storage and backups follow the same rule. |
| Data residency for indexed content | Embeddings and the chunks behind them are derived from source documents, so they usually fall under the same residency rules. Every component that touches indexed text, including embedding models, rerankers, backups and log sinks, must run in approved locations. | List every component that receives document text and confirm each location, including any hosted embedding or reranking API. |
| Authentication and administrative access | Search clusters often ship with weak defaults. The build needs authentication tied to the organization's identity provider, role-based access for administrators and TLS for node and client traffic. | Confirm the engine's supported authentication backends and whether role-based access covers collections or indices, not only the cluster. |
| Backup and restore of indexes | Restores must bring back both the keyword index and the vector data in a consistent state, and deleted or revoked content must not reappear from older backups. | Ask for a restore test that checks keyword and vector results together and confirms that deleted documents stay deleted. |
Which self-hosted engines support keyword and vector search together
Hybrid search needs a keyword index, a vector index and a way to merge their results. Some engines provide all three in one product, while others expect you to assemble the pieces. The options below differ mainly in how much is native and how much your team must build, test and operate.
Weaviate for native hybrid queries
Weaviate combines vector similarity, BM25 keyword filtering, hybrid search and reranking in one query interface, so a single request can merge keyword and vector results. Its source is BSD-3-Clause outside the repository's enterprise "wl" directory, which is licensed separately. Check which features your deployment needs sit outside that directory, and confirm how reranking is configured and scaled. Self-hosted authentication offers API keys, OIDC and RBAC, and replication is off by default and must be enabled per collection.
Milvus for dense and sparse hybrid
Milvus supports BM25 full-text search, sparse vectors and hybrid dense plus sparse search, so keyword-style relevance is built from sparse representations and fused with dense vectors. It is Apache-2.0 and runs in Standalone on one machine or Distributed on Kubernetes. Distributed deployments add etcd, object storage and a write-ahead log to operate. Authentication, TLS and RBAC are included, but you should confirm the fusion method and tuning you need with your own relevance tests.
OpenSearch when a cluster already exists
OpenSearch is Apache-2.0 and has long handled full-text search with mature analyzers, filters and relevance tuning. Its vector support sits alongside that text search, so teams with an existing cluster can often add hybrid queries without a new platform. The Security plugin provides RBAC, document and field-level security, field masking and audit logs. Confirm the vector features and versions your target release supports, and plan upgrades around its roughly eight-week minor release cadence.
PostgreSQL with pgvector for modest scale
pgvector adds vector columns and similarity indexes to PostgreSQL, so keyword search through PostgreSQL full-text features and vector search can share one database, one backup routine and one set of access controls. This is attractive when the database is already run, governed and restored well, and when collections stay modest. Full-text ranking and vector fusion are assembled in SQL, so your team owns the scoring logic. Check index types, dimension limits and filtering behavior before committing.
Qdrant needs direct confirmation
Qdrant is a common self-hosted vector engine, but the facts available for this page do not establish its hybrid keyword and vector capabilities, so this card does not claim them. Before shortlisting it, ask the vendor or check its current documentation for native sparse or keyword scoring, fusion methods, reranking support and its authentication and RBAC model. Run your own relevance tests on representative queries before treating it as a hybrid option.
How ranking and reranking choices change result quality
Hybrid search only improves results if the two result lists are combined sensibly, and the scores are the hard part. BM25 produces scores based on term frequency and document length, while vector engines return similarity values from the embedding model. These numbers are not on the same scale, so adding them directly lets whichever score has the larger range dominate the ranking. Engines handle this with rank-based fusion or score normalization, and the choice, along with any weighting between keyword and vector results, changes which documents reach the top. Treat the fusion method and weights as tunable settings, not defaults to accept from a vendor example. Confirm with each candidate engine which fusion options it exposes and how they are configured, including the Weaviate query options that combine keyword and vector ranking.
Tune those settings on your own queries. Build a test set of a few hundred real queries from search logs, support tickets or staff questions, and record which documents a qualified reviewer considers relevant for each one. Run every candidate configuration against that set and compare ranked results with a standard relevance measure. Include queries with product codes, names, dates and acronyms, where keyword matching matters most, alongside paraphrased natural-language questions, where vectors help most. Repeat the test whenever the embedding model, the chunking rules or the document set changes, because those shifts move the scores without any visible error.
A reranking model is a second pass that reorders the top results from the first-stage search using a model that reads the query and each candidate together. It adds value when the first stage returns a plausible but poorly ordered set, and the test set shows relevant documents appearing in positions below the ones users read. It does not fix results that were never retrieved, so check recall before adding one. A reranker is also a model dependency: it needs its own hosting, versioning, capacity and logging inside the same boundary as the rest of the stack. Weaviate lists reranking among its built-in query capabilities, which can reduce the number of moving parts, but the reranker model, its license and where it runs still need to be confirmed for your deployment.
How a hybrid search rollout proceeds
The sequence moves from a documented inventory of queries and content to a tested, monitored production search service, with a sign-off record at each stage so the engine choice, ranking weights and recovery path can be defended to security and business owners.
Inventory queries, content and permissions
The team lists the document and product sources, the identifier types each one uses (SKUs, case numbers, internal codes, free-text titles), the languages in use, and the permissions model that governs who may see each record. Search logs and sample queries from the business owners are collected alongside the content inventory. The output is a signed-off inventory document and a first sample of real query patterns, including the exact-match terms users expect to find. The step is done when the business owner and the security owner both accept the permissions model in writing.
Prove the engine on a representative corpus
DeployOpen runs a proof of concept on a representative slice of the corpus, not a toy dataset, comparing candidate engines such as OpenSearch, Weaviate, Milvus and PostgreSQL with pgvector against the same queries. The comparison covers native support for BM25 and vector search in one query path, filtering by permission at query time, operational fit with the existing platform team, and licence terms. The output is a written engine decision record that states what was tested, what failed, and which open items remain. Confirm each engine's current capabilities and licence terms against its own documentation before the decision is recorded.
Build the embedding and index pipeline
The engineering team builds the pipeline that chunks source content, generates embeddings with the chosen model, and writes both the keyword index and the vector index. The pipeline records which embedding model and version produced each vector so that a later model change is traceable. Re-indexing rules are written down: which source changes trigger a re-embed, how deletions propagate to the index, and how a full rebuild is scheduled without taking search offline. The output is a runnable pipeline, a re-indexing runbook, and a test showing that a changed or deleted source record disappears from search results.
Build the relevance test set and tune weights
Business owners and subject experts write a relevance test set: realistic queries paired with the documents or products that should rank highest, including exact identifiers, paraphrases and queries with no good answer. The team tunes the balance between keyword and vector scores, and tests whether a reranking step improves the top results enough to justify its added latency and cost. The output is a signed-off test query set with expected results, the scored baseline, and the chosen weights and reranker configuration. The step closes when the agreed test set passes at the level the business owner set before tuning began.
Harden authentication, TLS, RBAC and audit logging
The security work applies authentication through the organization's identity provider where the chosen engine supports it, encrypts node and client traffic with TLS, and assigns roles so that indexing services, search front ends and administrators hold separate privileges. Document-level or query-time permission filters are checked with users from each entitlement group. Audit logging is enabled and tested so that administrative actions and query access can be reviewed. The output is a hardening record that maps each control to the configuration key or setting used, plus a test report showing that an unauthorized user cannot retrieve restricted documents.
Run the backup and restore test
The team takes a backup of both the keyword and vector indexes, restores it into a separate environment, and confirms that search results from the restored system match the production baseline for the test query set. The restore procedure records which index versions and embedding model versions must match, since a vector index restored without its matching embeddings or model configuration will return misleading results. The output is a dated restore test record with the steps, timings observed, and any gaps. Confirm the recovery time and recovery point objectives with the business owner before the test is scheduled.
Cut over and monitor search quality
Traffic moves to the new search service in a staged way, with the previous search path kept available for a fallback period agreed in advance. Dashboards track query latency, error rates, index freshness, and the relevance test set re-run on a schedule to catch drift. Alerts are routed to the team that will run the service after handover. The output is a cutover record, a monitoring runbook, and a handover checklist confirming who owns re-indexing, upgrades and access reviews. The rollout is complete when the scheduled relevance run and the restore test both pass in production and the owning team accepts operations.
When an existing OpenSearch cluster is the simpler path
Extending an OpenSearch cluster is usually the lowest-friction path when keyword search already runs on it. OpenSearch is released under the Apache License, Version 2.0, and the project's FAQ does not describe a paid edition, so licensing does not add a new commercial dependency. OpenSearch is a fork of Elasticsearch 7.10, and its Dashboards derive from Kibana 7.10.2, so teams with that background will recognize most of the operating model.
- Same operating skills: Your team already manages shards, index lifecycle, snapshots and node roles, so new hybrid search work adds to existing runbooks rather than starting a new platform.
- Security plugin coverage: The Security plugin provides role-based access control, document-level and field-level security, audit logs and TLS, and supports SAML, OpenID Connect, LDAP and Kerberos backends.
- Maintenance policy: Versions stay in maintenance until the next major version enters maintenance or one year passes, whichever is longer, and maintenance receives security patches but no new features. Plan upgrades on that cadence.
- Release cadence: OpenSearch targets a new minor version about every eight weeks, with 3.9.0 released on September 29, 2026, so budget regular minor upgrades.
- Upgrade path: Teams still on Elasticsearch 6.0 through 7.10 can use wire compatibility and rolling upgrades, but confirm the migration route against the official migration documentation before committing.
Before committing, confirm which vector and hybrid query features your target OpenSearch version supports, including how keyword and vector scores are combined and whether reranking is available, because these have changed across releases.
A dedicated engine such as Weaviate or Milvus makes sense when vector workloads become the main driver of search architecture, or when you need features your OpenSearch version lacks. Weaviate combines vector similarity, BM25 filtering, hybrid search and reranking in one query interface, and Milvus supports BM25 full-text search, sparse vectors and hybrid dense plus sparse search. Running both systems means two clusters to secure, back up, upgrade and monitor.
- Native hybrid features: Both engines expose hybrid queries in a single API, which can simplify application code for retrieval-augmented generation.
- Operational overhead: A second stateful cluster adds nodes, storage, certificates, backup jobs and on-call duties. Milvus, for example, depends on etcd, object storage and a write-ahead log in its distributed mode.
- Licensing review: Weaviate's license splits between BSD-3-Clause code and a separate enterprise license for its
wldirectory, so confirm which features your deployment needs. Milvus is Apache-2.0. - Authentication and RBAC: Weaviate supports API key and OIDC authentication with custom roles, and Milvus implements authentication, TLS and role-based access control. Map these to your identity provider.
- Data synchronization: Keeping the search index and vector store consistent requires a pipeline for updates and deletions, which adds work when documents change.
Ask the vendor or your implementation partner to show the exact hybrid and filtering behavior at your expected vector count and dimensions, and to document the backup and restore procedure for both clusters.
pgvector adds vector storage and similarity search to PostgreSQL, which can be the simplest option for teams that already run PostgreSQL with mature backup and high availability. Keyword search then relies on PostgreSQL full-text search rather than BM25, so the ranking behavior differs from OpenSearch and from dedicated engines. Confirm the index types, dimension limits and filtering behavior in the pgvector version you plan to deploy.
- Existing controls: Database roles, TLS, backups and replication you already audit can cover embeddings stored alongside source records.
- Transactional consistency: Vectors and metadata can be written in the same transaction, which simplifies deleting embeddings when source records change.
- Scale limits: Large collections, heavy query rates and index rebuilds can compete with transactional workloads, so teams often split out a dedicated engine later.
- Ranking gap: Combining full-text rank with vector distance usually requires custom query logic, and you should test relevance on your own documents.
- Operational isolation: A search workload sharing a production database can affect transactional latency, so decide whether a read replica or separate instance is required.
Before choosing this path, test index build time, query latency and restore time on a copy of your real data, and confirm that your backup tooling captures the vector indexes.
Evidence auditors ask for on hybrid search
What audit logs will an assessor ask to see for hybrid search queries?
Assessors usually want a record of who ran which queries, against which index or collection, and when, plus any administrative changes to access. For OpenSearch, the Security plugin provides audit logs that can be configured to capture authentication events and requests, so the first task is to decide which categories to enable and where they are shipped. For Weaviate, confirm which request and authentication events the deployment records and how they reach your log platform, since that depends on your logging setup. Retention is a decision you own: agree the period with your compliance lead and make sure logs are stored outside the search cluster so they survive a rebuild. Ask DeployOpen to document the logging configuration and a sample of retrieved log entries as part of the readiness work.
How do I show access control per index or collection on a hybrid search system?
The assessor will want the role definitions, the mapping of roles to users or groups, and proof that the mapping matches your identity provider. In OpenSearch, the Security plugin supports role-based access control, document-level and field-level security, and field masking, so the configuration export for roles and role mappings is the core artifact. In Weaviate, the user management API assigns custom roles and permissions through RBAC, so export the role and user assignments from the running cluster. Collect a dated export, a list of which collections or indexes each role can read, and a test record showing a restricted user is refused. DeployOpen prepares the configuration and test evidence; the auditor decides whether it is sufficient.
What TLS evidence do auditors expect for a self-hosted search engine?
Auditors typically check that traffic between clients, nodes and any embedding service is encrypted, that certificates are issued by a trusted internal or public authority, and that weak protocol versions are disabled. OpenSearch's Security plugin provides TLS for node and client traffic, so the evidence is the transport and REST layer configuration, the certificate inventory with expiry dates, and a scan or command output showing the negotiated protocol. Weaviate and Milvus also document TLS options, but confirm the exact settings for your version in the vendor documentation. Keep the certificate renewal procedure with the evidence, because expired certificates are a common finding.
What backup and restore test records should I keep for a hybrid search index?
A backup file is not evidence of recovery. Assessors look for a documented backup schedule, the scope of what is backed up (indexes, collections, configuration, security settings), and dated restore tests showing the data came back and queries returned expected results. For OpenSearch, record the snapshot repository configuration and the restore run output. For Weaviate, record the backup configuration and the restore test with the replication settings in effect. Keep the restore test log, the time taken, the person who ran it and any errors. Restore tests should also cover security configuration, because a restored index without its roles is a control gap. DeployOpen can design and run these tests as part of an engagement that is agreed in writing.
What version and patch records does an auditor need for the search engine?
Assessors look for an inventory of the engine version in each environment, the upgrade history, and proof that security patches were reviewed and applied within the timeframe your own policy sets. For OpenSearch, the releases page describes how minor versions are maintained and that maintenance releases receive bug fixes and security patches, so keep the version inventory alongside the maintenance status of your line. For Weaviate and Milvus, record the exact release tags you run and the release notes you reviewed. Note that the 1.x and 2.x OpenSearch lines are at or near end of maintenance, so an unsupported version is a finding to resolve before the assessment. Ask your partner for a patch calendar and change tickets, not just a current version number.
How do I prove which embedding model and index version produced each search result?
This is the evidence most teams have not built yet. Store a record for each indexed object or batch that names the embedding model, its version, the dimension count, the index configuration and the date of ingestion. When you change the embedding model or re-index, the old and new records must both remain available so results can be traced to the configuration that produced them. Weaviate can vectorize at import time through integrated providers or accept pre-computed embeddings, so the evidence differs by pipeline: record the provider and model version if vectorization happens in the database, or record the pipeline job version if embeddings come from outside. Include this lineage in query logs where your policy requires it. Confirm with your engineering team how the ingestion pipeline writes these records before you promise them to an assessor.
Can our own team collect this evidence, or do we need a partner?
Many teams can collect the raw artifacts themselves: configuration exports, log extracts, backup and restore logs and version inventories. What takes more effort is designing the evidence so it is consistent, dated, retained and tied to change control, and mapping it to the control set your auditor uses. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do. A fixed-scope engagement can cover configuration hardening, logging setup, restore test design and an evidence pack, with the scope and deliverables agreed in writing before work starts. Ask any partner to show a sample evidence pack from a comparable environment and to state which items the auditor still has to verify.
Questions to ask an implementation partner about hybrid search
Start by asking how the partner measures relevance before any tuning begins. A credible partner builds a relevance test set from your own queries, including exact identifiers such as policy numbers, SKUs, part codes and error strings, where BM25 keyword matching usually outperforms pure vector similarity. Ask them to show the keyword recall on those identifiers, the recall on your top queries, and the baseline numbers they captured before changing anything. Ask whether they will hand over that test set, the relevance judgments and the scoring scripts when the engagement ends. If the answer to any of these is that no baseline was measured, or that tuning will be judged by how the results look in a demo, treat that as a warning.
Next, ask how fusion weights and the reranker are chosen and documented. Hybrid search in Weaviate and Milvus combines BM25 and vector scores, and the weighting or fusion method directly changes which documents reach the top. Ask which engine they recommend for your workload, why, and which reranker sits after the first stage, whether it runs on your own infrastructure, and how its latency is measured. Ask for a change log showing each weight change, the query set it was tested against and who approved it. Confirm the exact fusion and reranking options with the vendor for the version you plan to run, since these change between releases.
Finally, ask how authorization is enforced for every result, not only in the user interface. Each candidate document should be filtered by the caller's entitlements inside the query itself, using tenant, collection, partition or property filters, so that restricted text never reaches the response or a reranker. Ask how the partner tests this with a set of test users, and how they handle embedding changes: whether re-indexing is done in a new collection, how long the old one stays available for rollback, and how the team proves restores match the running version. Ask for the restore test record and the upgrade plan. An answer that relies on front-end filtering alone is a serious gap.
What hybrid search implementation costs and what it needs from you
What drives the effort of a hybrid search implementation?
The main drivers are corpus size, the number of languages, the identifier types you must match exactly, the permission model, and whether you add a reranker. A corpus of a few thousand product records with one language and simple permissions is a very different job from millions of documents across five languages with per-user access rules. Identifier types such as part numbers, SKUs, contract IDs and clinical codes need exact-match handling that behaves differently from free text, and each extra language adds tokenization, stemming and synonym work. Entitlement filtering adds design and test effort because every query must respect access rules. A cross-encoder or hosted reranker adds model hosting, latency testing and evaluation work. Ask the partner to show how each of these factors changes their scope.
Which parts of hybrid search are one-time work and which recur?
One-time work includes engine setup, the ingestion pipeline that extracts, chunks and embeds content, index schema design, and relevance tuning against a labeled set of queries. Recurring work includes re-indexing when the embedding model, analyzers or schema change, applying engine upgrades, monitoring query latency and error rates, rotating credentials, and refreshing relevance tests as the catalog and user behavior shift. Relevance tuning is often the largest one-time item and the most underestimated recurring one, because search quality drifts as content changes. Ask the partner to separate both lists in the quote so you can budget the run phase on its own.
Can our own team build and run hybrid search without a partner?
A team with experience in search engines, data pipelines and identity integration can build and run hybrid search internally, and many do. The usual gaps are relevance evaluation, which needs a labeled query set and someone who can read ranking results critically, and secure configuration of the engine, including authentication, TLS and role-based access. If your OpenSearch or Elasticsearch skills are already in place, adding BM25 and a vector field is often a smaller step than introducing a new engine. Before deciding, check who will own the pipeline, who will carry the on-call load, and whether the same people can run upgrades within the vendor's release and maintenance windows. A partner can cover any of these gaps as a fixed scope, leaving the rest with your team.
How long does a hybrid search rollout take?
Duration depends on scope, and no fixed timeline applies across projects. A single index over one content source with keyword and vector fields and no permission filtering is a much smaller job than a multi-source rollout with entitlement-aware filtering, several languages and a reranking stage. The phases that usually take the longest are access-rule mapping, which depends on how well your identity systems are documented, and relevance evaluation, which depends on how quickly your business owners can review results. Ask the partner for a phased plan with a named exit criterion for each phase, and ask which of your teams must be available and when.
What must our organization supply before implementation starts?
Three inputs matter most: representative sample queries, a set of documents or records that reflect the real content, and the access rules that decide who may see what. Sample queries should include common searches, rare identifiers, misspellings, and the zero-result queries your current search already logs. Documents should cover every format and language in scope, with owners who can answer questions about them. Access rules should be exported from the system of record, such as your identity provider or document management system, rather than reconstructed from memory. You will also need a named business owner who can judge result quality and a security contact who approves the engine's authentication design.
How does a quote follow from the written scope?
DeployOpen does not publish a price list. Most engagements are fixed-scope, so a quote follows from a written scope that states the content sources, document counts and languages, identifier types, permission model, search engine and deployment target, the reranker choice, the evaluation approach, and the handover items. Scope, deliverables and timelines are agreed in writing before work starts. Ask for the quote to list each deliverable separately, to state what the client supplies, and to show which items are one-time and which are offered as ongoing support or retainers. Ongoing support, upgrades and continuous testing are available as retainers, so a quote should show that option as its own line.
Does an existing OpenSearch cluster reduce the implementation cost?
It can reduce cost when the cluster is already operated, secured and backed up, because the engine, access controls and operational runbooks are in place. OpenSearch is released under the Apache License, Version 2.0, and the project's documentation covers installation with Docker, Helm, the OpenSearch Kubernetes Operator and several package formats. Its Security plugin supports SAML, OpenID Connect, LDAP and other authentication backends, plus document-level and field-level security. Confirm the cluster's version against the maintenance policy, because versions in maintenance receive security patches but no new features. Vector fields and hybrid query configuration should be verified against your exact version before the design is fixed.
What should the quote say about security and compliance evidence?
A quote should name the authentication backend, the role-based access design, the TLS configuration for node and client traffic, the audit logging scope, and the backup and restore procedure. It should also list the evidence the implementation produces, such as configuration exports, access reviews, and test records for permission filtering. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so the quote should make clear that independent auditors and certification bodies provide those outcomes. Ask which of the controls are in scope for your assessment before the design starts, so the evidence is collected from the beginning rather than reconstructed later.
How DeployOpen scopes and supports hybrid search
DeployOpen starts by writing the engine decision and the relevance test into the statement of work before any installation begins. The scope names the candidate engines (for example Weaviate, Milvus, PostgreSQL with pgvector, or an existing OpenSearch cluster), the document and product corpora to be indexed, the query types that must work (exact identifiers, free text and filtered lookups), and the fusion method and reranker to be compared. The relevance test is agreed in the same document: a fixed set of queries with expected results, judged by the business owners of the search, so that the choice rests on measured results rather than on vendor claims. Confirm with the client's search owner who signs off on the test set and what pass criteria they will accept.
Inside the client's own cloud accounts, data centers or air-gapped network, the work covers the deployment, its configuration and its hardening. For Weaviate, that means enabling API key or OIDC authentication, disabling anonymous access, assigning custom roles through its RBAC user management, and setting replication per collection. For OpenSearch, it means configuring the Security plugin for the client's identity provider, mapping roles, applying document-level and field-level security where catalog entries carry different entitlements, and enabling audit logs and TLS for node and client traffic. Backups, restore tests and the upgrade path are documented as part of the handover. Confirm which authentication backend and which upgrade window the client's operations team can support before design is final.
DeployOpen runs security testing against the search API and its authorization model, including whether a query filter or a hybrid request can return documents the caller is not entitled to see. Testing covers injection through query parameters, tenant or role boundary checks and error responses that leak field values. Ongoing support is available as a retainer and typically covers version upgrades, index rebuilds after embedding model changes, relevance regression checks and monitoring review. DeployOpen does not issue audit reports or certifications. It prepares configuration records, access reviews, test results and restore evidence so that the client's internal auditors or independent assessors can examine them.
