When you're monitoring thousands of devices, the choice of where you put your performance metrics matters. Every value collected by collectd, every response time recorded by pollerd, every streaming telemetry sample ends up stored as time series data, and that data has to keep up, scale out, and play nicely with the tools your IT Operators use day to day.

We've been making changes to the time series storage options in OpenNMS and now is a good moment to explain where we're headed and what it means for you.

Why Prometheus-Style Time Series Storage?

OpenNMS has long supported several time series backends. For example: RRDtool for traditional file-based storage, Newts on top of Apache Cassandra for horizontally scaled deployments, and a plugin-based path to many other Time Series Storage backends like Prometheus.

Going forward, we're focusing on that last option as the recommended scale-out path. Here's why:

  • Horizontal scalability done right. Prometheus-style stores are purpose-built for ingesting and querying time series at massive volumes. They've been hardened in production at organizations running well into the millions of active series.

  • First-class query integration. No matter the dashboarding platform your operators are using, their job is about quickly creating queries to make use of the data. The Prometheus Query Language (PromQL) lets you search your data quickly. It’s easy to adjust data with computation in-line, it’s templatable and portable, and it’s simple to write and understand.
  • A healthier ecosystem. Prometheus has become the de facto open-source standard for metrics. Choosing a Prometheus-compatible backend means more downstream tooling, more community know-how, and more flexibility over time. Customers today are using OpenNMS with Prometheus, Cortex, Mimir, Thanos, and Victoria Metrics – all of which support this Prometheus-style Time Series format.

If you're spinning up a new OpenNMS deployment today, or rethinking how to scale an existing one, a Prometheus-style backend is the path we're going to be investing the most in going forward.

Renaming the Cortex Plugin to Prometheus RemoteWrite Plugin

It’s been a bit of an undocumented feature that our Cortex plugin works with any Prometheus remote-write compatible time series backend. Users have been leveraging it for production workloads for quite some time. However, the name we initially chose isn’t a true reflection of the broad compatibility we offer and it’s caused some confusion. "Cortex" refers to one specific implementation, but the plugin works with the wider family of Prometheus-compatible databases that enable remote-write capability.

To better reflect what the plugin actually does, we have renamed the Cortex plugin to Prometheus RemoteWrite Plugin. The functionality is the same; the name is a more accurate description of the broader use case.

We’ve also got more updates planned for the Prometheus RemoteWrite Plugin thanks to the valuable feedback from Horizon users in our community, our Meridian customers, and our own developers and contributors.

What's Happening with Newts and Cassandra?

When Newts was introduced, Apache Cassandra was the most practical answer to "how do I scale this horizontally?" That landscape has changed. Purpose-built time series databases now do this job with less operational overhead, and they integrate more cleanly with modern dashboarding tools.

With that in mind, support for the Newts plugin (Cassandra-backed time series storage) will be discontinued with the upcoming Meridian 26 release.

Here's what that means in practice:

  • Meridian 26 will still ship with Newts support for existing Newts users. If you're already running on Newts, you can continue to do so through that release.
  • OpenNMS Meridian releases are supported for three years after their initial release. Anyone deploying Meridian 26 has a full three-year window of official Newts support — plenty of runway to plan and execute a migration on their own schedule.
  • After Meridian 26 reaches end of support, OpenNMS will no longer provide official support for the Cassandra backend. Newts will not be carried forward into subsequent Meridian releases.
  • OpenNMS is open source. Even after official support ends, the Newts code won't just disappear. The community has historically been a great resource for keeping useful pieces alive, and that option remains for users who want to continue running Newts beyond the official support window.

If you're a current Newts user, there's nothing you need to do tomorrow, but it's worth starting to think about your migration path now, while you have plenty of time on the clock. If you’re an existing Meridian Newts user then we have professional services and support options to help you with a migration plan. Just get in touch.

What's Happening with RRDs?

Nothing! At least, not yet. RRDs, or Round Robin Databases, have been used by OpenNMS since the early days and we aren’t moving on from them yet but the work we have done with Time Series Storage (TSS) and the work we are putting in to update and refine our Prometheus TSS plugin is getting us headed in a direction to eventually makes some moves with RRDs as well. Stay tuned.

Get Started

If you're planning a new OpenNMS deployment, or evaluating how to scale your existing one, here are some good next steps:

  • Read the docs. See the Time Series Integration Layer and Prometheus RemoteWrite Plugin documentation for current configuration details. We'll be updating the docs to reflect the new plugin name as part of the rename.
  • Pick a backend. VictoriaMetrics, Mimir, and Cortex are all good options. Choose based on the operational profile that best fits your team and the support you need.

  • Install OpenNMS with the new integration plugin. Get your OpenNMS install setup and running with the new Prometheus TSS Plugin.

Planning for What’s Next

Time series storage is one of those choices that quietly defines what your monitoring platform can do five years from now. By investing in Prometheus-style backends, renaming the Cortex plugin to reflect its broader compatibility, and giving Newts users a clear three-year runway, we're making the next decade of OpenNMS deployments more scalable, more interoperable, and easier to live with.

If you'd like to talk through what makes sense for your environment, contact us. We are happy to help you think it through.

Jump to section

About the Author: José Anés

OpenNMS Product Manager. My goal is to continuously improve the value our products provide to our customers and to make sure you can keep your IT Infrastructure working at the best of its capabilities. Always looking for an opportunity to have a conversation with our customers to understand their needs. Don't hesitate to contact me for any reason. Some background: Over 28 years of experience on the Networks, Systems and Applications Management industry. From developer, to Pre-Sales, to Custom Software Development Consulting, and then into Product Management. Focused on a wholistic view of every dependency that may impact the End User Experience. Extremely happy to be supporting the most flexible management application I have ever worked with.
Published On: June 5th, 2026Last Updated: June 5th, 20265 min readTags: , ,