The Hebrew Search Analyzer, a commercially licensed dictionary-based morphological analyzer, now installs on managed Amazon OpenSearch Service domains as a custom package. This post covers why Hebrew needs it, how installation differs from a self-managed cluster, and why it matters for hybrid search.

Hebrew Search Analyzer for Amazon OpenSearch Service: Morphological Hebrew Search on Managed Domains

The Hebrew Search Analyzer now installs directly on managed Amazon OpenSearch Service domains as a custom plugin package. Until now, teams running Hebrew search on Amazon's managed service had two bad options: ship without proper morphological analysis, or move to a self-managed cluster just to get shell access for plugin installation. Neither is acceptable for a production Hebrew search stack, and neither is necessary anymore.

Here's why that gap existed in the first place, and what changes with this release.

Why Hebrew breaks standard search analyzers

OpenSearch ships built-in language analyzers for more than 30 languages, from Arabic and Armenian through Thai and Ukrainian. Hebrew isn't one of them, and that's not an oversight - it's a consequence of how the language works. OpenSearch's own language analyzer documentation confirms the gap; the same is true of Elasticsearch.

A morphological analyzer for Hebrew is software that maps an inflected word form to its dictionary lemma using a root-and-pattern grammar and a reference dictionary, rather than by stripping suffixes with a fixed rule set. That distinction matters because Hebrew words are built by slotting a three- or four-letter root into a pattern (mishkal) and then attaching prefixes and suffixes for gender, number, tense, and possession - all without spaces. A single string like וכשלרהיטים can be a preposition-conjunction stack (and-when-to-the-furniture) glued onto a noun, and Hebrew orthography usually omits vowel marks (niqqud) entirely, so the same consonant sequence can map to several unrelated words depending on context. The stemming algorithms that work fine for English, French, or German - strip a suffix, maybe apply a rule table - fall apart on non-concatenative morphology like this. You need a dictionary and a grammar, not a suffix list.

Get this wrong and search quality degrades in a specific, measurable way: users type the natural inflected form of a word (which is nearly always what they type), the index holds a different inflected form of the same word, and a query that should match returns nothing. No amount of query tuning fixes that upstream - the tokens have to be normalized to the same lemma at index time and query time.

Why morphological search is critical in the hybrid search era

Hybrid search runs a lexical retriever and a dense vector retriever in parallel and fuses the two ranked lists, on the premise that BM25 covers exact matches and identifiers while embeddings cover paraphrase and semantic recall. That premise breaks quietly when the lexical retriever can't normalize inflected forms.

Without a morphological analyzer, BM25 over Hebrew text effectively degrades into literal string matching: a document containing מלפפונים won't match a query for מלפפון, even though any Hebrew speaker reads them as the same word. In a hybrid pipeline, that starves the lexical leg of the fusion - RRF or a weighted blend has nothing useful to combine with the dense retriever's ranking, because the keyword signal is noise on anything but exact string equality. You end up running vector search with an unreliable tiebreaker attached, not real hybrid retrieval.

That makes morphological correctness more important today than it was in the BM25-only era, not less. When lexical search stood alone, a weak Hebrew analyzer was a recall problem you could partly paper over with query expansion or fuzzy matching. In a hybrid pipeline, a broken lexical leg doesn't just underperform - it actively works against the fusion, because RRF and weighted blends assume both retrievers are independently contributing signal. Morphological normalization is the precondition that makes that assumption true for Hebrew. Feed the same field through the hebrew analyzer at index time and hebrew_query/hebrew_query_light at query time, and BM25 starts returning the recall it's supposed to: inflected forms, construct-state variants, and prefixed forms of the same lemma all match. That restores the actual value proposition of hybrid search - a lexical signal strong on exact terms and identifiers, genuinely complementary to a dense retriever's semantic recall, fused through RRF or weighted sum exactly as described in our guide to hybrid search architecture. For Hebrew-language product catalogs, legal archives, or support content, this is usually the difference between hybrid search that measurably beats BM25-only and dense-only baselines, and one that doesn't.

Commercial licensing

The Hebrew Search Analyzer is commercially licensed software: a proprietary, actively maintained Hebrew dictionary paired with the analyzer engine, plus direct integration support from the team that built it. Anyone evaluating it should plan for that from the outset - a valid license token is required on every platform it runs on, including Amazon OpenSearch Service, and none of the installation steps below do anything useful without one. It's also the production-hardened descendant of over a decade of Hebrew information retrieval work, going back to the open-source HebMorph project I started in 2010 to bring proper Hebrew retrieval to Lucene, Solr, and eventually Elasticsearch.

Hebrew Search Analyzer
Dictionary Proprietary, actively maintained
License Commercial, required on every platform
Platforms Lucene, Lucene.NET, Solr, Elasticsearch, OpenSearch, SQL Server FTS
Amazon OpenSearch Service Supported as a custom package
Support Direct vendor support

Query time exposes analyzers under a few distinct names: hebrew for indexing and full morphological querying, hebrew_query and hebrew_query_light for lighter-weight query-side expansion, and hebrew_exact when a field needs literal token matching without lemma expansion - useful for names, acronyms, and product codes where morphological normalization would hurt more than help.

Installing it on a managed Amazon OpenSearch Service domain

A managed domain gives you no shell, no opensearch.yml, and no ability to hit custom REST endpoints, so the installation path is structurally different from a self-managed cluster even though the analyzer behavior at query time is identical.

Self-managed OpenSearch Amazon OpenSearch Service
Install bin/opensearch-plugin install <url> Upload to S3 → create-package → associate-package
License PUT _hebrew/license Document in the hebmorph_license index
Dictionary overrides PUT _hebrew/additions or custom.txt Same document, additions field
_hebrew/* diagnostic APIs Available Not available
Applying a new build Restart the node Blue/green deployment

Before you can attach a custom package at all, the domain needs node-to-node encryption, encryption at rest, and enforced HTTPS with the Policy-Min-TLS-1-2-PFS-2023-10 TLS policy turned on. Custom plugins also require OpenSearch 2.15 or later and are only available in a subset of AWS regions, so check Amazon's custom plugins guide before you start.

The plugin is built against one exact OpenSearch version - Amazon only offers MAJOR.MINOR.0 releases, so a build has to match precisely. Once you have the right zip, installation is three AWS CLI calls:

# 1. upload the plugin to S3, in the same region as the domain
  aws s3 cp analysis-hebrew-3.1.0-commercial.zip s3://$BUCKET/analysis-hebrew.zip
  
  # 2. register it as a package (validation takes 10-25 minutes)
  aws opensearch create-package \
    --package-name analysis-hebrew \
    --package-type ZIP-PLUGIN \
    --engine-version OpenSearch_3.1 \
    --package-source "S3BucketName=$BUCKET,S3Key=analysis-hebrew.zip" \
    --region $REGION
  
  # 3. attach it to the domain via blue/green deployment (20-40 minutes)
  aws opensearch associate-package --domain-name $DOMAIN --package-id $PKG_ID --region $REGION

Because there's no _hebrew/license endpoint on a managed domain, licensing works through an index instead: the license token is a document in hebmorph_license, which the plugin polls every 30 seconds. That also means the license and any dictionary overrides survive blue/green deployments and node replacements automatically, since they live in the cluster's data rather than on a node's filesystem.

curl -X PUT "$ENDPOINT/hebmorph_license/_doc/default?refresh=true" \
    -H 'Content-Type: application/json' \
    -d '{"license": "<the license token we sent you>"}'

Confirm it took by analyzing an inflected word and checking that you get a lemma back, not just the original token:

curl -X POST "$ENDPOINT/_analyze" -H 'Content-Type: application/json' \
    -d '{"analyzer": "hebrew", "text": "מלפפונים"}'
  # tokens: מלפפונים$, מלפפון  <- the second token is the lemma

Search interface mock-up showing a Hebrew search box with the term "שולחן" and result rows including inflected forms like "שולחנות" and "השולחן"

The diagnostic _hebrew/* REST endpoints (check-word, status) don't exist on the managed service - Amazon only accepts plugins that extend analysis and search behavior, not ones that register new endpoints - so _analyze becomes your primary tool for verifying how a word gets tokenized, and CloudWatch logs (with ES_APPLICATION_LOGS enabled) replace the status endpoint for troubleshooting.

Key takeaways

  • Hebrew's root-and-pattern morphology and vowel-free orthography defeat suffix-stripping stemmers, which is why OpenSearch and Elasticsearch ship 30+ built-in language analyzers and none of them is Hebrew.
  • In a hybrid search pipeline, a working Hebrew analyzer is what keeps the lexical (BM25) leg meaningful - without it, the lexical side degrades to exact-string matching and hybrid search stops being hybrid.
  • The Hebrew Search Analyzer is commercially licensed software - a proprietary dictionary, vendor support, and a required license token on every platform, including Amazon OpenSearch Service.
  • On Amazon OpenSearch Service, installation goes through create-package/associate-package instead of opensearch-plugin install, and licensing lives in a hebmorph_license index document instead of a _hebrew/license API call, since managed domains expose neither shell access nor custom REST endpoints.
  • Verify the plugin is working by running _analyze on an inflected word and confirming you get a lemma token back, not just the original string.

If you're running Hebrew-language search on Amazon OpenSearch Service, or building hybrid retrieval over Hebrew content and want the lexical side to actually pull its weight, reach out - we built this analyzer and can get it running on your domain.