SQL Search

Beginning with 3.88 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 behaviour when using SQL search instead of Elasticsearch.

Positional Wildcard Patterns

Nexus Repository supports positional wildcard patterns for component searches when the following property is enabled:

nexus.search.multi.wildcard.regex.enabled=true

A positional wildcard pattern uses one or more asterisks (*) between known parts of a value. The matching parts must appear in the same order.

By default, wildcard patterns use standard Nexus Repository search behavior based on tokenized matching.

Supported Search Fields

Positional wildcard patterns are supported for the following component search fields:

Examples

Limitations

Positional wildcard patterns are not supported for format-specific fields, such as Maven base version, Docker tags, and npm scope.

Positional wildcard patterns are not supported for keyword search.

For these fields, wildcard patterns use standard Nexus Repository search behavior based on tokenized matching.

Performance Considerations

Positional wildcard patterns use regex matching, which is slower than standard searches.

To reduce search cost:

• Use trailing wildcards when possible, such as commons* instead of commons*lang.
• Avoid multiple wildcards for broad searches.
• Use exact matches when the specific value is known.

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-parser and Newtonsoft.Json, but may not match packages like myjsonlib that 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.

Search results

No results found.