In this guide:
- Database Models for NXRM
- External Database Architecture
- Internal Database Architecture
- Choosing a Model
Nexus Repository Manager’s (NXRM) architecture has been upgraded to support the use of 2 new database models: embedded H2 or external Postgres. These changes will help organizations meet their resiliency, scaling, and business continuity requirements. This guide will provide recommendations for existing deployments while reviewing some of the capabilities available to enterprise architecture.
Database Models for NXRM
NXRM currently uses an embedded Orient database to natively support highly available clusters. This technology has been critical for some organizations, however, it has presented challenges due to it’s high system requirements and inherent limitations. Our recommendation is to prioritize the migration to the new database models as OrientDB will eventually be removed from NXRM.
Starting with release 3.31, NXRM Pro users will have the option to either upgrade to the embedded H2 or to an external Postgres database, based on the current formats that are being used. New licensed instances can start with whichever model best meets their needs. NXRM administrators should expect to review the New Database Feature Availability documentation before proceeding with the migration as some features and formats will become available in later releases.
External Database Architecture
Having a resilient centralized repository is a common architecture for medium to large organizations. This architecture consolidates the repository configuration management and user access control under a primary repository manager instance. Often these organizations are more sensitive to artifacts not being available so maintenance outages should be kept to a minimum. Online backups of the database and components should occur frequently as well as regular testing of failover instances and recovery. In these situations, using Postgres to externalize the repository database is recommended.
The primary benefits of externalizing the database are to reduce downtime and increase availability of artifacts. The distributed architecture makes it easier to scale and will be the backbone for building fault-tolerant environments. There are distributions of Postgres that support load-balancing between highly available, replicated instances for both cloud and on-premise. The external database will be readily available to quickly transition to failover instances and shorten the time needed for upgrades. While the repository manager and the database could be configured on the same server, we recommend the database to reside on a separate server with a low latency connection to be more fault-tolerant.
- Postgres hot backups remove the requirement for frequent maintenance windows
- A more stateless frontend provides faster loading during startup and failover
- Postgres can be deployed as a replicated cluster for high availability
- Tighter integrations with cloud infrastructure
Internal Database Architecture
The new embedded H2 database is ideally suited for smaller or temporary deployments that require less resources and complexity. H2 is a lightweight, in-memory database with fast start times and high performance. Using the embedded architecture will not require outside management from a database administrator. They make excellent proxies for offloading traffic from the central server or as transient repositories for distributed teams.
- Faster initialization
- More performant indexing
- Ideally suited for small teams
- Low infrastructure requirements
Choosing a Model
For most enterprise organizations, the external Postgres database will be the best choice as the primary instances due to the scalability and resiliency details mentioned above. This will come at the cost of additional infrastructure requirements and will require either an in-house DBA or leveraging a cloud based managed service. As more state is externalized from Nexus Repository, the external database will be a requirement for multi-node clusters against the shared database and storage. Organizations that cannot not meet these requirements can still use the embedded H2. Not all features will be available for these new databases so please review the documentation for any restrictions that may apply. For assistance planning a migration, consult Customer Success or support channels.