Operations | Monitoring | ITSM | DevOps | Cloud

InfluxDB 3.2 is now available for both Core and Enterprise, bringing the general availability of InfluxDB 3 Explorer, a new UI that simplifies how you query, explore, and visualize data. On top of that, 3.2 includes a wide range of performance improvements, feature updates, and bug fixes. InfluxDB 3 Core is free and open source, optimized for recent data, and licensed under MIT and Apache 2.

The following serves as a practical guide for those looking to simplify their architecture by migrating to a Rust monolith. Earlier this year, the platform team at InfluxData undertook a major rewrite of our core account and resource management APIs, moving from Go to Rust and from a microservices architecture to a single monolith. This change supported a new administrative UI for InfluxDB Cloud Dedicated and aligns with our broader effort to rewrite the InfluxDB database engine in Rust.

Modern data centers generate enormous volumes of telemetry from servers, switches, cooling systems, power infrastructure, and environmental sensors. Operations engineers must capture, store, and analyze this data in real-time to monitor uptime, maintain energy efficiency, and perform predictive maintenance using AI. Legacy monitoring systems struggle to meet today’s volume, cardinality, and latency demands.

Data plays a critical role in shaping operational decisions. From sensor streams in factories to API response times in cloud environments, organizations rely on time-stamped metrics to understand what’s happening and determine what to do next. But when that data is inaccurate or incomplete, systems make the wrong call. Teams waste time chasing false alerts, miss critical anomalies, and make high-stakes decisions based on flawed assumptions.

Time series data, such as IoT sensor readings or stock market ticks, flow in fast, often at a rate of millions of points per second. Querying this data, especially years of historical records, can be slow and painful if using a nonspecialized database rather than a time series database like InfluxDB.

Data isn’t just a record of what happened—it shapes what happens next. Across industries, connected devices continuously stream time-stamped data that reflects the current state of machines, environments, and systems. This steady flow gives businesses a live view of their operations and the opportunity to catch issues early, adjust quickly, and operate more efficiently.

I’ve been building apps with SQL Server for years. Everything worked well until I started dealing with sensor data, stock trade volume, and IoT telemetry. As the volume of time-stamped records grew into the millions, I saw relational databases struggling with workloads they weren’t designed for. That’s when I explored time series databases. The performance improvements were significant, but what surprised me was the mental shift required.

If you’ve ever stood up multiple edge InfluxDB instances in remote locations and wished you could consolidate their data into a centralized instance for analysis, you’re not alone. That’s exactly why we designed Edge Data Replication (EDR) in InfluxDB v2. Now, with InfluxDB 3 Core and 3 Enterprise, we’re seeing new ways to handle replication using the brand-new Python Processing Engine.