InfluxData

Veteran infrastructure executive to lead product and engineering as InfluxData expands adoption of InfluxDB 3 SAN FRANCISCO, August 11, 2026 – InfluxData , creator of the leading time series database InfluxDB®, today announced the appointment of Satyam Vaghani as Chief Product Officer. Vaghani will lead product, engineering, and operations as the company expands adoption of InfluxDB 3 and advances the database for developers and enterprises building complex time series systems at scale. Vaghani brings more than two decades of experience building enterprise infrastructure products across storage, cloud platforms, edge computing, IoT, and AI, from developing foundational storage technology to founding and leading infrastructure software companies. At InfluxData, he will oversee the next phase of InfluxDB 3, building on the company’s long-standing technical leadership in time series as modern systems move beyond monitoring the physical world to understanding and acting on it in real-time.

Physical AI enables machines and industrial systems to perceive conditions, reason about them, and act in the real world. In industrial settings, as part of an industrial AI strategy, physical AI models can help organizations identify risks earlier, optimize operations, and respond to changing conditions in real-time. Delivering these outcomes starts with training AI models on detailed historical operational data. Then, when deployed, these models need access to real-time telemetry to interpret current conditions, make decisions, and automate actions. For organizations built around traditional historians, supporting model training and real-time operations creates new challenges and new opportunities. Where historians fall short for Physical AI Data historians remain essential systems for industrial operations. They create a durable record of process and equipment behavior, supporting engineering analysis, troubleshooting, reporting, auditability, and, where required, regulatory complia

Time series workloads rarely stay predictable for long. A system might begin with a few devices reporting a small set of measurements. As the fleet grows, new sensors come online, tags multiply, and query patterns change. A table that looked simple at the start becomes wide and sparse. A workload built around recent data expands into long-range analysis. As complexity grows, maintaining fast query performance and a predictable resource profile becomes much harder. InfluxDB 3.11 was built for that reality. Our last two releases gave users an early look at a set of performance improvements designed for heavier, more complex time series workloads. Today’s release of InfluxDB 3.11 makes those performance improvements GA in InfluxDB 3 Enterprise, bringing significantly faster queries on live data, greater flexibility for wide and ultra-sparse schemas, and more predictable performance under heavy load. The release also adds new Enterprise capabilities for backup and recovery, bulk data impor

Material Event filed 2026-07-30

When a satellite is drifting toward a fault, operators don’t need another dashboard full of disconnected charts. They need to know what changed, what it means, and what to check before the next ground pass closes. That’s the idea behind our satellite telemetry demo: a live mission-control experience built on InfluxDB 3 . The demo monitors a simulated fleet of 12 satellites, continuously ingesting telemetry such as onboard computer temperature, battery voltage, solar current, reaction wheel RPM, power draw, RF link margin, ground station, orbit pass, and attitude status. One satellite is actively degrading, while historical incidents provide useful context for comparison. You can check out the live demo here or watch the video to see it in action: Demo overview From Telemetry Stream to Operator Signal The main dashboard provides a fleet overview showing which satellites are online, which are currently in contact, and where anomalies are occurring. Operators can then drill into individua

The InfluxDB team has released five new Processing Engine plugins. They range from making it easy to call a hosted ML model to pulling in stock market data in real-time. Every one of them can be activated with a few terminal commands. No external services or tools—they all run inside your existing InfluxDB instance. Here’s what’s new, when you’d reach for them, and a few quickstart examples to get you going in minutes. Processing Engine primer If you aren’t familiar, the Processing Engine is an embedded Python runtime inside InfluxDB 3 that allows you to execute Python code on the following triggers: Schedule - Run code at scheduled intervals Data write - Runs whenever data is written to a table Request - A custom HTTP endpoint that handles incoming requests Plugins can query InfluxDB, transform your data, and write it back to a new table. They can also be used to hit external services outside InfluxDB. SageMaker inference The SageMaker plugin pulls rows of data, formats them how your

Every month, satellite operators perform thousands of orbital maneuvers as recommended by LeoLabs’ data. They don’t do it to reposition satellites, they do it to avoid hitting things. With tens of thousands of active satellites and other debris circling the Earth, adding new devices to orbit comes with risk. Satellites are expensive, high-tech devices that require a massive investment to engineer and launch. This means that to get a return on that investment, companies need their satellites to last a long time and to avoid the hazards posed by other satellites and debris in similar orbits. Space is big, but it’s becoming increasingly crowded as investment in the commercial space sector skyrockets. A satellite in low Earth orbit is unlikely to bump into something else on any given day, but when the expectation is that its lifespan will be on the scale of 5 to 10+ years—thousands of days—that small chance of collision becomes a greater risk. Collisions can take a satellite out, and witho

A new feature-bearing release for Telegraf is now available: Telegraf 1.39 — Release notes You can find the binaries for the latest Telegraf release on our Downloads page. Many thanks to all the open source community members who contributed to this effort! New plugins These are the newest plugins, first available in this version: GNMI dial-out input ( inputs.gnmi_listener ) Receive GNMI dial-out telemetry data pushed by network equipment such as Nokia SR OS devices. Please open a feature request to request support for your devices. Contributed by srebhan Important changes Here are some changes to highlight: OPCUA node discovery The OPCUA input plugins, both inputs.opcua and inputs.opcua_listener , can now be configured to discover nodes based on filtering patterns. This allows Telegraf to work in dynamic environments where nodes are added or removed on the server side. If configured, the plugin will browse available nodes on the server and filter them according to your settings. It wil

Here’s everything that shipped. Telegraf Enterprise reaches general availability Telegraf is the open source standard for collecting telemetry from infrastructure, applications, and devices. But what happens at scale? An enterprise running thousands of agents doesn’t have one collection problem; it has thousands of slightly different configs, no single view of agent health, and no safe way to roll out changes with confidence. Today, that usually means leaning on Ansible, Puppet, Chef, or some homegrown script nobody fully trusts. We built Telegraf Enterprise to solve that. Telegraf Enterprise reached general availability on June 24, 2026, giving teams a centralized way to manage, monitor, and support tens of thousands of Telegraf agents. It combines Telegraf Controller, a console for fleet management, with official InfluxData support. Open source Telegraf doesn’t change—teams get the same lightweight agent and 400+ official plugins. What changes is the operational layer above it: one p

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