Hybrid keyword and semantic site search on open source

Why hybrid keyword and semantic site search changes the build

Keyword site search does exactly what it was built to do: it matches the words a visitor types against the words on the page. The problem shows up when a visitor searches for "how do I close my account" and the page says "cancel your subscription," or when a synonym, paraphrase or plain-language question returns nothing. The short answer for most teams is that semantic results should be added on top of keyword matching, not swapped in for it, and the open-source choice depends on two things: where the embeddings come from and how much memory the vectors need. Meilisearch offers hybrid search that combines semantic and full-text results, with the Community Edition published under the MIT license. Typesense and OpenSearch offer vector search, but Typesense's server is licensed under GPL-3.0, which lets an organization run modified server code internally without publishing changes as long as it does not distribute the software. Your legal team should confirm that reading applies to how you plan to deploy it, and should check the Meilisearch Enterprise Edition terms if you expect to need features outside Community.

The embedding source is the decision that changes the architecture most. If the team sends page text to a hosted embedding API, content leaves your boundary and the design fails the sovereignty requirement the project was meant to meet. If embeddings are generated by a model running inside your own infrastructure, you own the model file, its updates and its hardware needs. Typesense documents that each vector needs 7 bytes of memory per dimension and that built-in ML models need roughly 2 to 6 GB of extra RAM, so a catalog with many long pages will need capacity planning before go-live. Ask your engineers to calculate vector memory from the number of documents, the model's dimension count and the replica count, and to confirm the same arithmetic on the platform you choose. Then ask the vendor or implementation partner to show how the embedder is configured and where its model files are stored.

Which platform fits hybrid search and why

Meilisearch, Typesense and OpenSearch can all return semantic results next to keyword results, but they differ in how hybrid queries are built, how vectors are stored in memory, how the server is licensed and what production looks like. The cards below set out where each one fits and what to check before you commit to an engine.

Meilisearch hybrid queries in one call

Meilisearch combines full-text and semantic retrieval in a single search request through its hybrid parameter and configured embedders, so typo tolerance, filters and facets keep working alongside vector results. The Community Edition is fully open source under the MIT license. The Enterprise Edition is governed by a commercial license or the Business Source License 1.1 and is not permitted in production without a commercial agreement, so confirm which edition your features require before you design around them.

Typesense vector search and GPL terms

Typesense adds nearest-neighbor vector search to its in-memory keyword engine, which suits teams that want one engine for typo-tolerant keyword and semantic results. Its server is licensed under GPL-3.0 while client libraries are Apache licensed. Running modified server code internally does not require publishing changes, but distributing that code does. Have counsel confirm that your deployment model fits these terms before you ship a modified build to partners or customers.

Typesense memory budget for vectors

Typesense holds keyword indexes and vectors in RAM, and each vector needs 7 bytes of memory per dimension. Built-in ML models add roughly 2 to 6 GB of RAM on top of the index. Multiply your document count by your embedding dimensions to size the cluster before you choose a node size. Confirm the memory figures for your own embedding model and record count with your engineers, because they change the hosting bill more than any other setting.

Typesense Raft clusters for production

Typesense uses Raft-based clustering for a highly available setup, and its guide strongly recommends a 3-node or 5-node cluster for production, tolerating one or two node failures respectively. A single node is fine for a proof of concept but leaves search down during restarts and failures. Plan for a cluster from the start, because vector memory is multiplied across nodes and the team must operate quorum, snapshots and rolling upgrades.

OpenSearch k-NN inside a wider stack

OpenSearch is released under the Apache License 2.0 and is a fork of Elasticsearch 7.10, so hybrid retrieval sits next to log analytics, dashboards and a mature query DSL. Vector search is one capability among many, which suits organizations that already run OpenSearch for other workloads. The cost is operational weight: node roles, shard sizing and replicas need dedicated skills, and you should confirm which vector and hybrid features your chosen version supports.

OpenSearch Security for access control

The OpenSearch Security plugin supplies role-based access control, document-level and field-level security, field masking, audit logs and TLS for node and client traffic. It also accepts SAML, OpenID Connect, LDAP and other identity backends. This matters when search results must respect entitlements, such as internal documents or regional content. Verify that the security configuration is in place before indexing sensitive content, because permission filters applied late can leak titles and snippets.

Algolia migration parity and gaps

Meilisearch and Typesense both publish Algolia migration guides, and Typesense supports Algolia InstantSearch widgets through an adapter. Typesense states its APIs are not wire-compatible and that it is at about 85% feature parity with Algolia, with server-side A/B testing, event tracking and built-in personalization missing. Meilisearch maps most Algolia settings but has no equivalent for some parameters such as aroundPrecision. List every Algolia feature your site uses and test each one against the candidate before choosing.

Requirements that shape a hybrid search build

This table lists the requirements that most change a hybrid keyword and semantic search build, the source each one traces to, and what it means for the platform and infrastructure. Read each row as a question to answer before choosing an engine or edition. The main takeaway is that memory for vectors, the embedding model location and the edition licence are fixed early, while relevance measurement is what shows whether the semantic layer earns its cost.

Requirement	What the source says or asks for	Build consequence
Keyword relevance baseline	Meilisearch README lists typo tolerance, filtering and faceted search; Typesense README describes typo-tolerant keyword search	Record current keyword results on a fixed query set first, so any semantic gain is measured against a real baseline
Embedding model location	Typesense can run built-in ML models, which need roughly 2 to 6 GB of extra RAM per its system requirements guide	Decide whether embeddings come from a model inside the search cluster or an internal model service, and confirm where query text is sent
Vector dimension and memory	Typesense guidance: each vector needs 7 bytes of memory per dimension, on top of 2 to 3 times the searchable field size for keyword search	Multiply vector count by dimensions to size RAM before the catalog grows, and confirm the equivalent sizing for OpenSearch and Meilisearch with each vendor
Query latency	Typesense holds its index in memory; OpenSearch and Meilisearch sizing depends on node resources and index layout	Benchmark hybrid queries on production-sized data, since embedding calls add time to each query that keyword search does not pay
Filtering by permissions or language	OpenSearch Security provides document-level and field-level security; Meilisearch README lists multi-tenancy for application tenants	Permission and language filters must apply inside the hybrid query, so confirm they work on the vector side as well as the keyword side
Licence obligations for the chosen edition	Meilisearch Community Edition is MIT, but Enterprise Edition needs a commercial agreement for production; Typesense server is GPL-3.0; OpenSearch is Apache 2.0	Confirm which features used in the semantic path sit in the edition you deploy, and record what GPL-3.0 obligations apply if you distribute modified server code
Measurement of result quality	Typesense migration guide notes that server-side A/B testing and built-in event tracking are not included	Plan click and conversion logging, a judged query set and an A/B method outside the engine before switching traffic to semantic results
Backup and recovery of vectors	Vector data sits in the same index as documents on each platform, so it is restored with the index	Include embedding regeneration time in the recovery plan, since rebuilding vectors after an embedding model change can be the longest step

Where embeddings come from and what vectors cost in memory

Before you choose an engine for semantic results, decide where the embeddings come from, because that choice sets your data location, your memory budget and your run cost. There are three sources. The first is a built-in ML model inside the search engine, which keeps text and vectors inside the cluster but adds RAM to every node that runs it. The second is a model you host next to the search cluster, on your own servers or in your own cloud account, which keeps content in your boundary but adds a GPU or CPU service to operate, patch and scale. The third is an external embedding API, which is the simplest to start with but sends query text and possibly indexed content to a third party. For regulated sites, that transfer needs to be assessed before any content is embedded.

Memory is the cost most teams underestimate. Typesense's system requirements guide gives three rules you can use as a starting point: keyword search typically needs 2 to 3 times the size of the searchable fields in RAM, each vector needs 7 bytes of memory per dimension, and built-in ML models need roughly 2 to 6 GB of extra RAM. A 768-dimension embedding, for example, works out to 5,376 bytes per vector before index overhead (illustrative). Multiply that by your document count and by any replicas, then add the built-in model footprint. Ask your engine vendor or implementation partner for the equivalent figures for OpenSearch and Meilisearch in your own environment, using a sample of your real content, because the published guidance for those engines differs and your field sizes will drive the result.

Confirm three things before you budget. Check which embedding model the engine supports or will call, its output dimension, and whether a change of model forces a full re-embedding and reindex of the catalog. Check whether the chosen source keeps query text inside your boundary, and whether it is covered by your data processing terms. Finally, run a memory test on a representative subset with the planned replica count and record peak RAM during indexing and during query load. Those numbers, not list prices or general rules, should set the node sizes you ask a partner to quote.

How a hybrid search rollout runs

The sequence moves from measuring today's keyword results to a staged release behind a flag, so the team can show whether semantic results help before every user sees them. Each phase ends with a named artifact that the next phase depends on.

Measure baseline keyword results
Before any engine change, the search owner and a product or content lead build a baseline query set from the last several months of logged searches, weighted toward queries with zero results, high abandonment or frequent reformulation. The team records current click-through, null-result rate and the top-ranked documents for each query. The step closes with a baseline query set and a scored snapshot of today's keyword results that every later test is compared against.
Inventory content, fields and data location
The platform team and content owners list every source that feeds the index, including page bodies, product attributes, PDFs and access-controlled content, and mark which fields are searchable, filterable or displayed. They also confirm where query logs and indexed text may be stored under the organization's data rules. The step closes with a field-level data inventory and a sizing sheet that estimates index size and, for vector search, the memory each embedded field will add.
Decide the embedding source
The architect chooses where vectors come from: a model the engine runs internally through its built-in embedding support, an embedding service the organization already hosts, or a model supplied as files and run inside the boundary. The decision weighs data residency, hardware, update cadence and who maintains the model. The step closes with a written embedding decision record that names the model, its licence terms, the dimensions it produces and the re-embedding process when the model changes.
Build a proof of concept on an index copy
The implementation team loads a copy of the production index into a separate instance of the chosen engine, configures hybrid or vector search with the embedding decision, and runs the baseline query set against it. Keyword settings stay identical so differences can be traced to the semantic layer. The step closes with a proof-of-concept report that lists which queries changed, the memory observed at the sizing sheet's projections, and any settings that needed correction.
Test relevance and latency
Reviewers grade the baseline queries side by side, keyword only against hybrid, with judgments recorded per result and blind to which version produced it. The team also measures query latency and indexing time under realistic load, and tests permission filters so that semantic results never return documents a user cannot see. The step closes with a relevance scorecard, a latency result against the agreed target, and a list of accepted tuning changes.
Release in stages behind a flag
The engineering team places the hybrid query path behind a feature flag and exposes it first to internal users, then to a small share of traffic, comparing click-through, null-result rate and reformulation against the baseline. The keyword path stays live and selectable at all times. The step closes with a release log of exposure steps and metrics, and a rollback runbook that switches traffic back to keyword search and states who can execute it.
Hand over operations
The implementation partner and the internal operations team walk through index rebuilds, re-embedding after model changes, backup and snapshot procedures, node monitoring and alert thresholds, and the upgrade path for the engine. Ownership of the embedding model, the query set and the scorecard transfers to named internal staff. The step closes with signed-off operational documentation and a scheduled review of the relevance metrics after go-live.

Questions teams ask before adding semantic site search

What does it cost to add semantic results to site search?

The cost comes from four places: the embedding source, the memory needed for vectors, the size of the cluster, and internal staff time. Self-hosted Meilisearch and Typesense are free to run under their open source licenses, so the recurring spend is infrastructure and people. Typesense's system requirements guide says each vector needs 7 bytes of memory per dimension, and built-in ML models need roughly 2 to 6 GB of extra RAM, so the number of documents and the embedding dimension set the memory bill. If you use a hosted embedding API, you pay per call and per token, and that line recurs with every reindex. Ask for a quote that separates one-time build work from recurring hosting, model calls and support.

How long does it take to add semantic search to an existing site?

The timeline depends on the state of your current search, the number of content types you index, and how much relevance tuning you need. A team with clean content and a working keyword engine usually spends most of the time on the embedding pipeline, reindexing and evaluation rather than on the search engine itself. Migrating from Algolia adds time for mapping settings: Meilisearch's migration guide maps NeuralSearch to the hybrid parameter with embedders, and some parameters such as aroundPrecision have no equivalent. Any duration should appear in the written, fixed scope, with the phases and acceptance checks named.

What do we need to provide before the work starts?

Three inputs decide most of the early progress. Content owners need to name the fields that should be searchable, the fields that should filter results, and the content that must never appear in results. Query logs, ideally several months of them with the query, result count and click data, give you a baseline for measuring improvement. Infrastructure access means a test environment in your cloud account, data center or private network, plus access to your identity provider if searches are restricted by role. Confirm with your security team how query logs are stored, because they can contain personal data.

Can our internal team build this without a partner?

Yes, if the team has engineers who have run search clusters and a clear owner for relevance decisions. The hard parts are rarely the first install. They are the reindexing pipeline from the application database, backups, upgrades, and the evaluation work that tells you whether semantic results beat keyword results for your queries. Typesense recommends a highly available 3-node or 5-node cluster for production, and OpenSearch has its own node roles and maintenance cycle, so operations need someone on call. A partner is most useful when staff time is short or when you want the scope, deliverables and handover agreed in writing before work starts.

How do we know semantic results actually improved search?

Measure it against the keyword baseline using the same queries, not by reading a few results and judging them. Build a fixed set of real queries from your logs, have reviewers rate the top results for each query, and track click-through, zero-result rate and time to a successful click on live traffic. Run the keyword and hybrid versions side by side so the comparison is fair. Typesense's migration guide notes that server-side A/B testing and built-in event tracking are not included in the engine, so you will need your own analytics or an experimentation tool to split traffic. Agree the success thresholds before the test starts.

Does Meilisearch Cloud or Typesense Cloud pricing change the choice?

Hosted pricing changes the comparison, but it does not remove the questions about data location and vectors. Meilisearch's pricing page lists Meilisearch Cloud from $20 per month with a 14-day free trial, and usage-based plans such as $30 per month for 100K documents and 50K searches. Typesense Cloud provides dedicated clusters sized from 0.5 GB to 1024 GB of memory across three to seven nodes, with bandwidth billed separately. Compare those published figures with the memory and node counts your own workload needs, and confirm where the cloud region sits, whether query logs leave your boundary, and how the embedding model is hosted. Check current prices on the vendor pages before you decide.

Which engine should we choose for hybrid search with vectors?

Choose by the data and operations you already have. Meilisearch offers hybrid search that combines semantic and full-text results and supports multi-tenancy, and its Community Edition is MIT licensed. Typesense includes vector search and Raft-based clustering, and its server is GPL-3.0, which lets companies run modified code internally without publishing changes unless they distribute it. OpenSearch is Apache 2.0 licensed, offers role-based access control and audit logs, and suits teams that already run it for logs. Confirm each engine's current vector and hybrid capabilities against its documentation and your own test set before you commit.

How to measure whether semantic results improve search

Offline relevance testing answers a narrow question before any user sees the change: for a fixed set of queries, do the hybrid results put the right pages higher than keyword-only results do? Start with a labeled query set drawn from real site logs, including head queries, long-tail queries, misspellings and queries with no obvious keyword match. Reviewers then grade the top results for each query, usually on a simple scale, and the grades become the baseline for comparison.

Query set design: Include queries that keyword search already handles well, so you can detect regressions as well as gains.
Judging rubric: Write down what a relevant result means for your content before reviewers start, and have two reviewers score a sample to check agreement.
Ranking metrics: Compare how high the first relevant result appears and how many relevant results sit in the top positions for each mode.
Segment reporting: Split scores by query type, such as product codes, questions and brand names, because hybrid search often helps one type and hurts another.
Frozen snapshot: Rerun the same queries against the same index snapshot after every tuning change so the comparison stays fair.

Before relying on this tab, confirm with your content owners that the labeled set covers each site section and language you serve.

What to ask an implementation partner about hybrid search

Start by asking the partner to show, not describe, delivered work on the engine you have chosen. For Meilisearch, that means hybrid search with embedders configured through the hybrid parameter; for Typesense, vector fields and nearest-neighbor queries; for OpenSearch, k-NN indexes alongside the keyword query. Ask for a redacted architecture or configuration from a past engagement, the query and index settings they changed, and what they would do differently. A partner who can only talk about the engine in general has not yet run semantic search in production. Ask which embedding model they used, whether it was hosted in the client's network, and how the vector dimensions were set, since a mismatch between the model and the index is one of the most common causes of poor results.

Next, ask how embedding models reach your network and how they are updated. Hosted embedding APIs send query text and indexed content to a third party, which matters for data residency and for the query logs that count as personal data in many jurisdictions. Ask the partner to state where each model file lives, who approves a new model version, how the index is rebuilt when the model changes (vectors from different models are not interchangeable), and how that process is tested before go-live. For Typesense, ask whether the built-in ML models will run inside your cluster and how much extra RAM they need. Require the answer in writing, because it determines the offline update path if you operate in a restricted network.

Then ask for the memory sizing method, not a single number. A credible answer starts from the searchable field size, applies the keyword multiplier in the Typesense system requirements guide, adds 7 bytes per vector dimension, and adds headroom for the embedding model and growth in record count. Ask the partner to show the calculation for your catalog and to state how it changes with replicas and the high-availability node count. Ask for the relevance test design as well: a set of real queries drawn from search logs, graded results agreed with your business owners, a baseline from keyword-only search, and a comparison of hybrid results on the same set. Ask how click data will be measured and who signs off that results improved. Finally, require a written, fixed scope that names the engine version, the indexes, the query types in scope, the test set and the acceptance criteria, plus the support terms after go-live, including who tunes relevance when the catalog changes.

How DeployOpen scopes and supports hybrid site search

DeployOpen plans, builds, tests and hands over hybrid keyword and semantic site search inside your own infrastructure, on the engine that fits your catalog, tenancy and data rules. Each engagement starts from a written, fixed scope so you can check what the semantic layer changes before any work begins.

How we scope

Written scope covers the engine choice, the fields to embed, and which queries should use semantic ranking.
We confirm where embedding models run, and whether query text and indexed content may leave your network.
We size vector memory from your document count and chosen dimensions, and document the assumptions behind that estimate.

How we build

We configure keyword, typo tolerance and filters alongside the hybrid or vector layer on your chosen engine.
We build the indexing pipeline from your content source, including updates, deletions and reindexing when the embedding model changes.
We test relevance with a fixed set of real queries, comparing keyword-only results against hybrid results before go-live.

How we hand over

You receive configuration, index schemas, pipeline code and runbooks for the keyword and semantic layers.
Documentation records the evaluation method, query set and results so your team can repeat the comparison later.
We walk your engineers through monitoring of query latency, memory use and zero-result queries after launch.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover engine version upgrades, embedding model changes and periodic relevance reviews against a fixed query set.
Before scoping support, confirm with us which engine version, memory limits and backup schedule your environment requires.