Nexus Repository Database
Nexus Repository has two databases available. Use the following table to choose a database for your deployment.
See configure PostgreSQL for new instances
See migrating to a PostgreSQL for existing instances
Database | Appropriate For |
|---|---|
External PostgreSQL (Preferred) | The following features are only available for PostgreSQL deployments.
|
Embedded H2 |
Nexus Repository instances used beyond these levels may become unstable. Sonatype is not able to guarantee support for your deployment beyond these limits. |
Embedded H2 Database
H2 is a lightweight, open-source relational database management system written in Java. It is used as the default embedded database in file-based mode, running in the same Java process as Nexus Repository. There's no need for a separate database server, making it easy to set up and ideal for a self-contained and portable environment. It serves as the data store for Nexus Repository's internal metadata, such as user and role management, repository configurations, and search indexes.
Recommended Usage
The H2 database is great for quickly getting started and basic workloads but is not designed for mission critical deployments. Here are some deployment use cases for Nexus Repository with H2 database:
Development and Evaluation: H2 is a perfect choice for development, testing, and proof-of-concept deployments. Its lightweight nature and simple setup allow developers to quickly spin up a local instance of Nexus Repository for their needs.
Small, Non-Mission-Critical Workloads: We recommend using the embedded H2 database only for small workloads. This is defined by specific metrics, such as a maximum of 200,000 requests per day and 100,000 components.
Single-Team Deployments: H2 is suitable for deployments that serve a single team with a limited number of users and concurrent operations.
Disposable/Temporary Deployments: For instances that are not intended to be long-lived or where data loss is not a significant concern. Common for remote endpoints proxying components from a centralized Nexus Repository server.
Limitations for H2 Database
While quick and easy to use there are significant limitations to using H2 database for Nexus Repository.
Scalability and Performance: H2 is not designed for high-concurrency or large-scale enterprise deployments.
Production Use (Beyond Small Scale): For any mission-critical or large-scale production environment, use an external PostgreSQL database scaled to your production requirements.
Concurrency Issues: H2's concurrency model may lead to performance degradation and increased deadlocks in high-traffic scenarios.
Data Corruption Risk: There is a heightened risk of data corruption, particularly if the server is not shut down properly, a power failure occurs, or for larger datasets.
No High Availability: H2 does not support high availability.
Legacy Orient Database
Nexus Repository's legacy embedded OrientDB database is in extended maintenance as of August 2024. Nexus Repository deployments must migrate off of OrientDB.
You must remain on the 3.70.x version line if you are unable to migrate at this time.
The migration from Orient's NoSQL database to PostgreSQL has introduced fundamental changes in the external behavior of Nexus Repository.
Features not supported for PostgreSQL The Legacy high availability clustering (HA-C) and community formats are not supported for PostgreSQL environments.
The Bower format has been removed.
External plugins will not work External plugins that introduce new repository types, interact with repository content, or interact with the database directly need to be updated to accommodate the PostgreSQL database.
Backup and restore Existing OrientDB backups are not compatible with PostgreSQL and there is no similar task for backing up the PostgreSQL database in Nexus Repository.
Logging Logging related to database interactions is different.
Asset paths require a forward slash The asset name matchers are interpreted differently. Regular expressions are no longer anchored by default meaning that results are different for cleanup policies and asset references using the API. References to assets require a forward slash in front of a path to work.
Groovy scripting is not recommended Groovy scripts accessed undocumented Nexus Repository APIs that need to be updated to work. For both security and forward compatibility reasons, we recommend making use of the public REST API as much as possible rather than using Groovy scripting.
Coordinate-based content selectors Content selectors that use coordinates are deprecated in PostgreSQL and are no longer supported.
Changes impacting webhooks events When performing component cleanup, Nexus Repository no longer generates DELETED events for each component and assets deleted during component cleanup. Instead, there is an event of type PURGED containing the IDs of all deleted assets and components. More events of type UPDATED are generated during repository uploads.
Major Changes to Asset Name Matcher Regular Expressions
Regular expressions used in cleanup policies for path and name matching are handled differently when queried in Orient than in other environments. More content may be removed from repositories during cleanup.
Anchored queries match the entire asset name when there isn’t a wildcard in the regex.
In Orient, the Asset Name Matcher uses Lucene regular expressions that are anchored by default.
H2 and PostgreSQL environments use Java regular expressions that are not anchored.
Example of an Expression That Matches More Items After Migration to PostgreSQL/H2
This example contains the following assets for consideration:
/antlr/antlr/2.7.2/antlr-2.7.2.jar /org/antlr/antlr-master/3.1.3/antlr-master-3.1.3.pom
A cleanup policy sets the Asset Name Matcher using the following regular expression.
antlr.*
Cleanup in OrientDB would only match the first item while H2 and Postgres queries will remove both components.