News and Notes from the Makers of Nexus | Sonatype Blog

Modernizing Nexus Repository: Moving Beyond OrientDB

Written by Aaron Linskens | April 09, 2026

If you're running Sonatype Nexus Repository or Sonatype Nexus Repository Community Edition (formerly known as Nexus Repository OSS) on OrientDB, you're operating on a legacy database architecture that is no longer aligned with current security and platform requirements.

Support for OrientDB in Nexus Repository is now fully sunset. Deployments using OrientDB will no longer be supported.

While issues in newer architectures have been addressed, they cannot be fully remediated within the legacy OrientDB-based stack. The result is a growing gap between what can be secured and what can no longer be maintained.

In this post, we explain:

The Problem: OrientDB Is No Longer Defensible

Older Nexus Repository versions (below 3.70.5) rely on an architecture built around OrientDB and outdated software dependencies.

That stack now carries:

  • High-severity vulnerabilities.

  • Active exploitation in the wild.

  • No complete patch path.

Remaining on OrientDB introduces increasing operational constraints. Security fixes cannot always be backported. Platform innovation is moving elsewhere.

PostgreSQL is now the recommended and actively supported database for Nexus Repository. It offers measurable improvements in performance, better support for high availability and cloud-native architectures, and access to new and future product capabilities not being built for OrientDB.

The Decision: Two Supported Paths Forward

Once you decide to move off OrientDB, there are two supported migration paths forward.

Both approaches eliminate dependence on OrientDB. The difference is how much infrastructure responsibility your team wants to retain.

Option A: Move to Sonatype Nexus Repository Cloud (Recommended)

The fastest and most secure path forward is to move to Nexus Repository Cloud.

Benefits of this move include:

  • Fully managed infrastructure.

  • Automatic updates and patching.

  • Reduced operational overhead.

  • Built-in scalability and resilience.

  • Eliminates database management entirely.

This approach removes the operational burden of database management entirely and ensures you're always running on a current, supported architecture.

Option B: Stay Self-Hosted and Migrate to PostgreSQL

If you need to remain self-hosted, the supported path is:

This path preserves your deployment model while aligning your system with the supported and actively developed database layer.

However, this path still requires infrastructure ownership, ongoing patching and maintenance, and careful migration execution.

Setting Up Your Repository for the Future

Moving off OrientDB is ultimately about aligning your repository with a supported, secure, and forward-looking architecture.

By combining Sonatype's migration guidance with modern DevOps practices and automated workflows, you can turn a complex migration into a structured, repeatable process — one that reduces risk while improving long-term maintainability.

For detailed migration steps, prerequisites, and troubleshooting guidance, refer to the full migration guide or connect with a Sonatype migration specialist for tailored support.