Skip to main content

Nexus Repository Database Options

Sonatype Nexus Repository has two database options:

  1. An external PostgreSQL database (Preferred) - Requires a paid Pro license

  2. An embedded H2 database

This topic will explain the database options and benefits of an external database.

Important

Sonatype Nexus Repository's legacy embedded OrientDB database entered extended maintenance in August 2024. All Sonatype Nexus Repository customers are highly encouraged to migrate off of OrientDB. However, if you are unable to migrate, note that you will need to remain on the 3.70.x version line. Versions 3.71.0 and above do not support OrientDB.

The table below can help you choose the right database mode for your deployment. We also have a comprehensive set of Nexus Repository reference architectures to help you plan an appropriate deployment for your scale.

Database Mode

Appropriate For

External PostgreSQL (Preferred)

Requires paid Pro license

  • Mission-critical deployments of any size

  • Enterprise deployments

  • Cloud deployments (AWS, Azure)

  • Deployments in Kubernetes

  • Deployments planning to use a resilient or highly available (HA) deployment model

  • Dynamic backups for a shorter maintenance window

  • Deployments wishing to use any of our PostgreSQL-only features

Embedded H2

  • Repository OSS deployments

  • Smaller workloads (supported* maximum 20,000 requests per day and 100,000 components; see the Nexus Repository reference architectures )

  • Single-team deployments

  • Non-mission-critical deployments

  • Disposable deployments (e.g., temporary proxies)

* If using Sonatype Nexus Repository beyond these supported levels, it may become unstable and behave in unexpected ways. Sonatype will not be able to guarantee our ability to support Sonatype Nexus Repository usage beyond these limits. See our Nexus Repository reference architectures.

The following tasks can help your PostgreSQL database achieve optimum performance over time. These should be done outside of normal working hours to reduce impact on active users as the tasks can impact performance while running.

The following features are only available for PostgreSQL deployments; note that PostgreSQL requires a paid Pro license.

While we have made every effort to keep Nexus Repository's external behavior consistent while moving away from OrientDB, there are a number of differences, including some unsupported features and formats.

The following features/formats are not supported for H2 and PostgreSQL environments:

  • High Availability Clustering (HA-C) - Replaced by new High Availability Deployment Options, which require a PostgreSQL database.

  • Bower format

  • Community formats (APK, Composer, CPAN, Puppet)

Note that when migrating to an H2 or PostgreSQL database, unsupported formats will not be migrated, and you will not be able to add new formats that your database does not support.

You will need to update external plugins that introduce new repository types, interact repositories or repository content, or interact with the database directly to be compatible with the new data access approach.

In OrientDB environments, the Asset Name Matcher (part of our Cleanup Policies feature) uses Lucene regular expressions; in H2 or PostgreSQL environments, it uses Java regular expressions. The major difference is that the Lucene regular expressions are anchored by default (meaning that they must match the entire asset name if there isn’t a wildcard somewhere in the regex). Java regular expressions are not anchored by default.

This means that a regular expression that only matched specific options before migrating to H2 or PostgreSQL may match more items after migration.

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

The example Sonatype Nexus Repository instance has a cleanup policy where the Asset Name Matcher uses the regex antlr.*.

When running cleanup on OrientDB, /antlr/antlr/2.7.2/antlr-2.7.2.jar is removed while /org/antlr/antlr-master/3.1.3/antlr-master-3.1.3.pom was not removed.

After upgrading to an H2 instance and re-running the same cleanup policy, both components were removed.

You can back up the embedded H2 database using the same process you've used before, but you will need to use the Admin - Backup H2 Database scheduled task.

Any existing OrientDB backups will not be compatible with either of the new database options. Nexus Repository will no longer handle external PostgreSQL database backups; this will be the system administrator's responsibility.

References to Assets via the REST API now require a forward slash in front a path to work. For example ticketlist.txt now must be /ticketlist.txt.

There are no changes to log file locations, but any logging related to database interactions will be different.

  • Asset events contain the same information as before except that the value assigned to the asset name now begins with a forward slash. Beginning the asset's name with a forward slash is not specfic to webhooks.

  • There are no changes to the contents of a Component event.

  • The following event types are generated for respository uploads:

    • Asset and Component events of type CREATED - the quantities of these are the same as before.

    • Several Asset and Component events of type UPDATED - more events of this type are generated.

  • The following scenarios will emit an event of type PURGED containing the IDs of all deleted assets and components:

    • When performing component clean up. Nexus Repository no longer generates DELETED events for each component and asset deleted during component clean up.

    • Whenever deleting the last component from a maven repository.

  • Deleting individual assets/components (i.e., not via component clean up) from a repository generates the same number and types of events as before.

Path-based content selectors are fully compatible with the new architecture. However, we are using the transition to remove a deprecated feature: coordinate-based content selectors. These are any content selectors with references to format-specific coordinates.

There are several benefits to using an external database:

  • Easier to scale deployment; required for our High Availability Deployment Options

  • Leverage managed fault-tolerant cloud databases: AWS Aurora, RDS, Azure, etc.

  • Improved container orchestration such as Kubernetes and OpenShift

  • Fully available during backups

  • Support for multi-AZ cloud deployment models

  • Simpler and easier disaster recovery

Additional database options for Nexus Repository Manager

The pages below provide detailed information for migrating your Nexus Repository database:

Warning

  1. Unsupported formats will not be migrated; you will not be able to add new formats that your new database does not support. Review Feature Availability for PostgreSQL and H2 Databases and ensure that your new database supports all of your formats before attempting the migration.

  2. Migration is a one-time process; attempts to migrate again will overwrite data.