InfluxData

InfluxDB 3 Explorer 1.9 makes it easier to work with your existing queries. Whether you’re migrating Flux queries to SQL or you’ve been writing in InfluxQL for years, this release helps bring your existing queries forward instead of starting from scratch. For teams moving to v3 from earlier versions of InfluxDB, query migration is often one of the last major hurdles. Explorer 1.9 introduces an AI-assisted Flux-to-SQL converter to help automate that process, while also bringing InfluxQL directly into Explorer. On top of that, this release adds two new live sample data simulators, an improved plugin log viewer, search across every list page, and query error history. Convert Flux queries to SQL InfluxDB 3 uses SQL and InfluxQL to query data, but many teams still have Flux queries powering dashboards and alerts they’d rather not rewrite by hand. The new Flux-to-SQL converter (beta) does that translation for you . You’ll find it as a new tab in the Data Explorer, right next to SQL and Influ

When a team uses an internal Slack channel for everything from contact form submissions to deployment alerts and server warnings, the notification engine quickly becomes critical infrastructure. When the same team builds that engine as a product for other teams to use, the bar gets even higher. Mumu is an all-in-one productivity platform for modern teams. While most companies stitch together separate SaaS tools for org charts, agile estimation, internal Q&A, skill mapping, recognition, and notifications, Mumu offers all of those as connected modules under a single subscription. The premise is that your organizational structure shouldn’t be replicated across five different databases; it should live in one place and flow into every workflow your team uses. In this blog, we will go over why the Mumu team rebuilt their monitoring stack on InfluxDB 3 and how the migration went. Why pull-based monitoring stopped making sense Like many teams running their own infrastructure, Mumu started

New centralized controller enables teams to manage tens of thousands of Telegraf agents as a single system SAN FRANCISCO – June 24, 2026 – InfluxData , creator of the leading time series database InfluxDB, today announced the general availability of Telegraf Enterprise , a new offering that gives organizations centralized control over large-scale Telegraf deployments. With automated configuration management, fleet-wide visibility, enhanced security, and commercial support, teams can operate tens of thousands of agents as a single system, while reducing the complexity of running telemetry pipelines across distributed environments. With more than five billion downloads and 400+ plugins, Telegraf is the open source standard for connecting any data source to any destination across cloud, edge, and physical infrastructure. As deployments grow to tens of thousands of agents, teams often rely on fragmented tools and manual processes to manage configuration, maintain consistency, and monitor f

Summary: Telegraf Enterprise is now generally available. It combines Telegraf Controller, a centralized management console for Telegraf, with official support from InfluxData. Open source Telegraf remains unchanged. Telegraf Controller is free to start with built-in limits, while a Telegraf Enterprise license unlocks higher-scale limits, audit logging, LDAP/OIDC integration, and commercial support. Telegraf has become the standard for collecting telemetry across cloud, edge, and physical infrastructure. With more than five billion downloads and 400+ official plugins, Telegraf is the open source standard to connect virtually any data source to any destination. Over the years, we’ve seen Telegraf evolve from a lightweight collection agent into a foundational part of production infrastructure. But as deployments grow, the challenge shifts from collecting telemetry to managing the systems that collect it. Large Telegraf deployments require consistent configurations across environments, cle

Satellite operations depend on telemetry as the primary interface to systems that teams cannot directly inspect. Once a spacecraft reaches orbit, signals such as battery levels, temperature, signal strength, and fault codes become the foundation for understanding system health and maintaining control. Telemetry streams continuously, so the underlying data system becomes a critical control point that needs to handle a constant, heavy flow of data. When that system cannot ingest, query, and manage data efficiently, dashboards lag, investigations slow, and the clarity teams rely on begins to erode. Relational data vs. satellite telemetry Relational data organizes information into structured records with consistent fields and defined relationships. A business application might represent customers, orders, and products as related datasets, making it easy to answer questions such as which customer placed an order or which products were included in a purchase. This relational model works well

In our last release, we introduced a beta of performance updates designed for heavier, more complex time series workloads. InfluxDB 3.10 expands that beta to include enterprise features that give teams more control as they scale and manage larger workloads in InfluxDB 3. This release adds end-to-end backup and restore, row-level deletes, bulk import from Parquet, user management, and an RBAC preview to the previous performance beta. It also includes cross-database plugin queries, a new readiness endpoint, and compaction improvements for InfluxDB 3 Enterprise. Together, these updates help teams evaluate the next phase of InfluxDB 3 performance and scale with more of the operational tooling they need to manage real workloads. We’re inviting customers to test this next phase of InfluxDB 3 performance and scale, share feedback, and help shape the path to general availability. Expanded capabilities for the performance beta The performance improvements we previewed in InfluxDB 3.9 continue t

Getting InfluxDB 3 up and running is a pretty lightweight process with the installation script . Getting time series data into it is the next step, and for exploration, basic testing, or scenarios where you don’t have a stream of time series data ready to write, that can be a point of friction. That hurdle is particularly high when you want to test the rest of the system around the data you’d be writing: dashboards, alerts, replication, network connectivity, edge devices, server sizing, or Processing Engine workflows—you don’t always have the ability to start writing production data into a freshly-installed database, or you may not have that data yet. Two new InfluxDB 3 plugins help with exactly that: the Bird Tracking Simulator and the Signal Generator. Both are scheduled plugins that generate data directly to InfluxDB 3, making it easy to start writing realistic sample data with a single trigger. The Bird Tracking Simulator creates synthetic bird telemetry, while the Signal Generator

Satellite mission operators depend on telemetry to understand spacecraft health, ground system performance, and mission status in real-time. Operation signals help teams identify risks, investigate anomalies, and keep operations moving. When a spacecraft enters safe mode or signal strength drops during a contact window, teams need trusted telemetry immediately. But mission data moves quickly across operational systems, and every handoff makes it harder to control. How can teams keep telemetry fast, useful, and available while maintaining control over sensitive mission data? Why ITAR and data residency matter for telemetry For satellite operators, sensitive mission data raises two practical questions: who can access the data, and where can it go? ITAR and data residency requirements bring those questions into the monitoring conversation. ITAR, or International Traffic in Arms Regulations, controls how certain defense-related products, services, and technical data can be shared. In pract

Predictive maintenance is one of the most compelling use cases for time series data. Instead of waiting for equipment to fail or servicing it on a fixed calendar regardless of condition, you watch the live sensor data and act when it indicates that a failure is coming. That “watch the data and act” loop is exactly what the InfluxDB 3 Processing Engine was built for. In this tutorial, we’ll build a working predictive maintenance plugin from scratch. We’ll install InfluxDB 3 Core , load a well-known public dataset of jet engine sensor data, write a Python plugin that runs inside the database to estimate each engine’s Remaining Useful Life (RUL), and have it raise maintenance alerts automatically. By the end, you’ll have an end-to-end system that you can adapt to pumps, motors, HVAC units, CNC machines, or any other instrumented asset. What we’re building Here’s the architecture at a glance: Sensor data lands in InfluxDB 3 Core. We’ll use NASA’s C-MAPSS turbofan engine degradation dataset

For many operational time series workloads, machine learning can’t operate in the historical way, where data is compiled once and models are trained offline. Sensor readings, infrastructure metrics, application telemetry, energy data, industrial measurements, and financial ticks all share a basic property: the next datapoint is more useful when the system can respond to it immediately (or at least close to immediately). When a model learns in the same flow that ingests data and reacts to incoming data as it’s written, things like anomaly detection, short-horizon forecasting, and adaptive thresholding all become a lot more useful. Enter three new River -based plugins for InfluxDB 3: River Anomaly Detector River Auto-Profiler River Forecaster These plugins are built for the InfluxDB 3 Processing Engine and leverage River, a Python library for online machine learning. If you’re unfamiliar with it, the Processing Engine is an embedded Python VM that runs inside InfluxDB 3 and can execute p

Renewal notices don’t arrive with a subject line that says “modernization conversation enclosed.” They show up as a line item in procurement, usually with a larger number than the previous year. Most teams sign and move on. The ones that pause tend to find the renewal moment is a useful forcing function, not to rip out the historian, but to ask whether the current architecture can support what the business needs over the next three years. If any of the following sounds familiar, that audit is worth running before you sign. Sign 1: Your renewal quote is higher, and so is your tag count The math used to work. When the historian was first deployed, per-tag pricing was predictable. You knew the count, you knew the cost, and the line item made sense against the operational value it delivered. However, that equation breaks down as instrumentation expands. For example, AVEVA PI customers are seeing renewal pressure even as their tag counts increase. Some organizations have seen AVEVA pricing