SQL Search
Beginning with this release, Nexus Repository Manager uses SQL table search instead of Elasticsearch (ES). This change applies to all editions of Nexus Repository Manager (Pro and OSS) and affects how search queries are processed internally.
This page explains the search behaviour differences that some users may observe after upgrading, particularly when using wildcard searches or advanced search queries.
Scope of Change
Search is now executed directly against the configured database. Nexus Repository Manager supports two databases for SQL search: PostgreSQL and H2. PostgreSQL is intended for production use and provides scalable performance and relevance-based search results. H2 is intended for development and testing only and may behave differently when searching large datasets.
What is Unchanged
The move to SQL search does not change how you interact with search in Nexus Repository Manager. Search endpoints, query syntax, and supported repository formats remain the same. Exact match searches continue to behave as before, and no reindexing or manual configuration is required as part of the upgrade process.
Search Behaviour Differences
The following table summarizes the key differences in general search behavior when using SQL search instead of Elasticsearch.
Feature | SQL Search | Elastic Search |
|---|---|---|
Case Sensitivity | Case-insensitive | Case-insensitive |
Wildcard Support | Trailing wildcard only, minimum 3 characters (for example, spring*) | Supports trailing and leading wildcards (for example, *spring) |
Fuzzy/Similar Matches | Not supported | Supported |
Stemming/Root Matching | Not supported | Supported |
Stop Word Removal | Not supported | Supported |
Relevance Ranking | Supported with PostgreSQL; not supported with H2 | Supported |
Phrase Search | Supported with quotes; matches the exact phrase | Supported with quotes; may also match similar phrases due to stemming or fuzzy matching |
Term Splitting | Without quotes, terms are split on spaces and common delimiters | Similar term splitting with more flexible matching |
Database Consideration
Search behaviour and performance vary depending on whether SQL search is backed by PostgreSQL or H2.
H2 is suitable only for development and testing environments. As repository size grows (more than 10,000 components), search performance may degrade, and result ranking is not available.
PostgreSQL is recommended for all production deployments. It scales to large numbers of components, supports relevance-based ranking, and provides performance comparable to the previous Elasticsearch-based implementation. Use PostgreSQL if you expect high search volumes or have a large number of components.
Repository Format Behaviour
Most repository formats behave the same with SQL search as they did with Elasticsearch. However, some formats may return slightly different results in specific search scenarios.
NuGet V3
NuGet V3 search supports both exact and wildcard queries, but with some important changes:
Wildcard Support: SQL search only allows wildcards at the end of a term (for example, json*). Leading or embedded wildcards (such as *json or js*n) are not supported.
Matching Behaviour: Searches are more precise. For example, searching for json will match
json-parserandNewtonsoft.Json, but may not match packages likemyjsonlibthat only contain the term as a substring.Best Practice: For exact results, use the full package ID (e.g.,
packageId:Newtonsoft.Json). For broader results, combine multiple search terms.
NuGet V2
NuGet V2’s autocomplete feature continues to return up to 30 package IDs that match your prefix query.
Performance: SQL search may provide faster autocomplete responses, especially for prefix matches.
Behaviour: The results and matching logic remain consistent with previous versions.
npm V1
npm V1 search remains largely unchanged:
Search terms: You can enter space-separated terms, which are matched against package names, descriptions, and keywords.
Result consistency: The order and content of search results are consistent with previous behaviour. Up to 250 results may be returned, depending on configuration.
PyPI
PyPI search supports both exact and wildcard queries, with some restrictions:
Wildcard Support: Only suffix wildcards are supported (e.g., django*). Leading wildcards (such as *django) are not allowed.
Matching Behaviour: Searches are more precise. For example, searching for django will match "django" and "django-rest", but not "pre-django".
Best Practice: Use specific package names or suffix wildcards for best results.