InfluxData Blog - Heather Downing

Real-Time Flight Telemetry Monitoring with InfluxDB 3 Enterprise

Heather Downing (InfluxData) — Tue, 29 Jul 2025 08:00:00 +0000

When Microsoft Flight Simulator 2024 generates telemetry data at 30-60 FPS, capturing and processing that stream in real-time becomes a fascinating engineering challenge. We built a complete telemetry pipeline that reads over 90 flight parameters through FSUIPC, streams them to InfluxDB 3 Enterprise, and displays them in real-time dashboards that respond in under 5 milliseconds.

This isn’t just about gaming (although it IS fun)—it’s a blueprint for building enterprise-grade aviation telemetry systems that can scale from flight training simulators to operational aircraft monitoring.

The architecture: streaming aerospace telemetry

Our data pipeline uses aerospace simulator data in a realistic testbed for enterprise telemetry systems.

Key Components

Microsoft Flight Simulator 2024: Where the flight telemetry data points originate from

FSUIPC7: Interface to flight simulator memory using the simulator’s SimConnect API

C# Data Bridge: Processes batches of memory block reading with FSUIPC Client DLL for .NET

InfluxDB 3 Enterprise: Time series database with last n-value caching and compaction

Next.js Dashboard: Dual-mode visual app of real-time instruments and historical analysis

Reading flight telemetry data efficiently

Microsoft Flight Simulator exposes hundreds of data points through FSUIPC7 offsets. Reading each individually creates additional overhead of 90+ separate API calls every 16-33 milliseconds.

Solution: Memory Block Strategy

Instead of individual reads, we organized related metrics into logical memory blocks using the FSUPIC Client DLL for .NET:

_memoryBlocks = new Dictionary"string, MemoryBlock"
{    // Position, attitude, altitude
    { "FlightData", new MemoryBlock(0x0560, 48) },
    { "Engine1", new MemoryBlock(0x088C, 64) },
    { "Engine2", new MemoryBlock(0x0924, 64) },    // Flight controls, trim       
    { "Controls", new MemoryBlock(0x0BC0, 44) },
    { "Autopilot", new MemoryBlock(0x07BC, 96) },    // VOR, ILS, navigation
    { "Navigation", new MemoryBlock(0x085C, 32) },
    { "Fuel", new MemoryBlock(0x0B74, 24) },    // Callsign, tail number
    { "AircraftData", new MemoryBlock(0x3130, 72) }
};

Performance Impact:

Before: 90+ individual FSUIPC calls per frame = 2,700-5,400 calls/second
After: 8 memory block reads per frame = 240-480 calls/second

Each memory block read fetches multiple related parameters in a single operation, dramatically reducing the communication overhead with the flight simulator.

Writing to the database without bottlenecks

Writing individual telemetry points to a database would create a network bottleneck. At 60 FPS with 90+ fields, that’s thousands of individual database writes per second.

Solution: Intelligent Batching

// Batching configuration
MaxBatchSize: 100
MaxBatchAgeMs: 100 milliseconds

The system buffers telemetry points and flushes when either condition is met:

Size trigger: 100 rows of line protocol, each row consisting of 91 data points as fields/tags
Time trigger: 100 ms elapsed since last flush

Real-World Performance

Average write latency: 1.3 ms per row
Sustained throughput: Easily handles thousands of metrics per second
Data consistency: Reliable data collection during extended testing

This approach captures approximately six complete flight data snapshots per database write operation, maintaining near real-time performance while minimizing database overhead.

Monitoring data visually in real-time

Traditional time series queries for “current” values are expensive. Consider this typical query:

SELECT * FROM flight_data 
WHERE time >= now() - INTERVAL '1 minute' 
ORDER BY time DESC LIMIT 1

This scans recent data, sorts by time, and returns the latest point. This may be acceptable for historical analysis, but too slow for real-time cockpit displays.

Solution: Last Value Cache (LVC)

Data from InfluxDB 3’s built-in Last Value Cache (LVC) drives the Cockpit tab on the dashboard, which displays only the most recent data point. This is good for the current heading, attitude, GPS location, altitude, airspeed, vertical speed, etc.

Using SQL to query the LVC:

SELECT * FROM last_cache('flight_data', 'flightsim_flight_data_lvc')

LVC is an in-memory cache that maintains the most recent values for each metric (at the time of the last WAL flush), enabling instant access without a storage layer round-trip.

LVC Configuration for Flight Data:

influxdb3 create last_cache \
  --database flightsim \
  --table flight_data \
  --key-columns aircraft_tailnumber \
  --value-columns flight_altitude,speed_true_airspeed,flight_heading_magnetic,flight_latitude,flight_longitude \
  --count 1 \
  --ttl 10s \
  flightsim_flight_data_lvc

Performance Transformation:

The LVC enables cockpit displays that update at 5 FPS (200 ms intervals) while users experience them as instantaneous. The database typically returns the LVC row in less than 10 milliseconds.

Optimizing storage for streaming data

High-frequency telemetry creates storage challenges. At 90+ fields × 60 FPS, we generate thousands of data points per second, creating hundreds of small files that hurt query performance. It’s time to save some space and optimize our query performance!

Flight Sim Data Compaction Strategy

We set the following environment variables to configure our InfluxDB server:

# COMPACTION OPTIMIZATION
INFLUXDB3_GEN1_DURATION=5m
INFLUXDB3_ENTERPRISE_COMPACTION_GEN2_DURATION=5m
INFLUXDB3_ENTERPRISE_COMPACTION_MAX_NUM_FILES_PER_PLAN=100

# PERFORMANCE TUNING
INFLUXDB3_DATAFUSION_NUM_THREADS=16
INFLUXDB3_EXEC_MEM_POOL_BYTES=40%
INFLUXDB3_PARQUET_MEM_CACHE_SIZE=40%

# REAL-TIME DATA ACCESS
INFLUXDB3_WAL_FLUSH_INTERVAL=100ms
INFLUXDB3_WAL_MAX_WRITE_BUFFER_SIZE=200000

Why These Settings Work Together

Compaction Optimization breaks data into smaller 5-minute files instead of the default 10-minute files. This creates more frequent but smaller cleanup operations that don’t overwhelm the system (we ran this on a Windows gaming laptop that was also running Flight Simulator). We also limit how many files get processed at once (100 vs 500 default) to prevent performance spikes. (Learn more about InfluxDB 3’s generation-based compaction strategy.)

Performance Tuning allocates more memory resources for both query execution and Parquet file caching, improving read performance by keeping more data in memory and allowing more parallel query processing threads.

Real-Time Data Access reduces write-ahead log (WAL) flush interval from 1 second to 100 ms, making data available for queries much faster. The increased buffer size accommodates more writes before forcing a flush, balancing throughput with latency.

Measured Results:

142 compaction events automatically triggered over a 24-hour period
85% average reduction in the size of new data written since the previous compaction
File optimization: Significant reduction in file count (example: 127 small files → 18 optimized files)
Query performance: Faster historical data access due to fewer files and improved data organization

Our monitoring system polls the database directory size every 10 seconds. In the graph above, you can see decreases in disk usage, which indicate WAL file deletions after the snapshot, and compaction events that reorganize the data into Parquet files for faster querying. This is available to view on the Data tab of the dashboard.

Disk Usage Comparison: InfluxDB 3 Core vs Enterprise

In order to differentiate between disk space savings due to WAL file deletion and data compaction into the Parquet files, we compared the performance of InfluxDB 3 Core and Enterprise; compaction is an Enterprise-only feature. While Core registered a disk usage drop every 15 minutes, Enterprise did so more often. For a fair comparison, we compared both at the 15-minute mark and found:

Core dropped from around 500MB to 230MB due to WAL file deletion
Enterprise dropped from around 160MB to 30MB due to both WAL file deletion and compaction

Enterprise’s starting size was lower because it had already gone through previous deletion/compaction events, but we can determine from these numbers that without compaction or WAL file deletion, we would have 500MB of data. WAL file deletion reduces this by 54% to 230MB. Compaction then brings that 230MB down to 30MB—an 87% reduction from compaction, for a 94% total reduction overall.

NOTE: These percentages represent savings of new data written since the directory size last dropped and are sequential, not compounding.

Two-tier dashboard architecture

The Next.js dashboard demonstrates two patterns for different use cases:

Cockpit Tab: Real-Time Instruments

Uses LVC for instant current values, perfect for simulating aircraft instruments:

// Based on an LVC of the `flight_data` measurements in the
// `flightsim` bucket  called `flightsim_flight_data_lvc`
// with a key column of `aircraft_tailnumber` and the fields
// `flight_altitude`, `speed_true_airspeed`,
// `flight_heading_magnetic`, `flight_latitude`,
// `flight_longitude`, `speed_vertical`,
// `autopilot_heading_target`, `autopilot_master`,
// `autopilot_altitude_target`, `flight_bank`, `flight_pitch`,
// `aircraft_airline`, `aircraft_callsign`, and `aircraft_type`
const q = ```
  SELECT * FROM last_cache(
    'flight_data', 'flightsim_flight_data_lvc')`;

// Send the query to the InfluxDB server REST endpoint
const dataResponse =
  await fetch(`${endpointUrl}api/v3/query_sql`, {...});

Displays:

Current heading
Altitude
Airspeed
GPS coordinates
Attitude
Autopilot settings

Performance: Sub-10 ms database response enables smooth 5 FPS updates that feel real-time to the person monitoring visually.

Data Tab: Trends and Historic Analysis

Uses traditional SQL queries for historical analysis and system monitoring:

SELECT * FROM flight_data 
WHERE time >= now() - INTERVAL '1 minute' 
ORDER BY time DESC LIMIT 20

Features:

Recent measurements table with metric filtering
Database size monitoring over time
Compaction effectiveness tracking
Historical trend analysis

Update frequency: 1-second refresh cycle, appropriate for trend analysis without overwhelming the interface.

NOTE: For a single-client read scenario like ours, reading data directly from object storage is quite performant. However, if your use case requires multiple users or systems to read simultaneously, consider how a Distinct Value Cache (DVC) can add efficiency.

Real-world applications

This project, while a fun challenge and excellent testbed, offers a blueprint for going beyond simulation into operational aviation systems:

Flight Training Organizations

Real-time instructor oversight: Monitor student performance during simulator sessions
Objective assessment: Data-driven evaluation of flying skills and decision-making
Scenario replay: Historical analysis for post-flight debriefing sessions

Aircraft Manufacturers

System validation: Test avionics behavior in controlled environments
Performance modeling: Compare simulated vs actual aircraft characteristics
Pilot training programs: Develop type-specific training curricula

Research and Development

Human factors research: Study pilot workload and performance patterns
Safety analysis: Investigate scenarios and incidents in controlled settings
Technology integration: Test new systems before expensive flight testing

Getting started: complete implementation guide

Ready to build your own real-time flight monitoring system? The complete source code, configuration examples, and setup scripts demonstrate how. Whether you’re developing training systems, research platforms, or just enjoy MSFS, this example provides a good foundation.

Prerequisites

Microsoft Flight Simulator 2024 (for PC)
FSUIPC7 for MSFS 2024 (licensed version recommended for full data access)
FSUIPC Client DLL for .NET
InfluxDB 3 Enterprise v3.2 (self-hosted)
.NET 8.0 SDK for the data bridge
Node.js 22+ for the dashboard

Repository Structure

msfs2influxdb3-enterprise: C# data bridge application
FlightSim2024-InfluxDB3Enterprise: Next.js dashboard and demo setup

Hardware Requirements

This demo was developed and tested on a 2025 Alienware 16 Aurora Gaming Laptop running Windows (the only way MSFS is playable) with:

Intel Core i7-240H (10-core processor)
64GB DDR5 RAM
2TB NVMe SSD
NVIDIA GeForce RTX 5060 (8GB)

The memory-intensive nature of real-time telemetry processing, InfluxDB’s in-memory caching, and Microsoft Flight Simulator 2024’s requirements make adequate RAM the most critical component for smooth operation. While high-end specs aren’t strictly required, we recommend:

Minimum: 16GB RAM, quad-core processor, SSD storage
Recommended: 32GB+ RAM for optimal InfluxDB 3 Enterprise performance with large datasets
Storage: SSD recommended for database performance and flight simulator load times

Results may vary based on hardware configuration and system specifications.

Key Technical Achievements

LVC enables true real-time cockpit displays with consistent sub-10 ms query performance.
Automated compaction makes continuous telemetry economically viable, which results in an average of 87% storage savings.
Memory block reading strategy significantly reduces FSUIPC overhead while maintaining data fidelity.
Intelligent batching delivers enterprise reliability with stable operation during extended testing.
Microsoft Flight Simulator provides a realistic testbed equivalent to real aircraft telemetry streams.

From gaming to enterprise monitoring, the principles remain the same: efficient collection, smart caching, and automated optimization enable real-time insights at any scale.

Moving from Relational to Time Series Databases

Heather Downing (InfluxData) — Tue, 10 Jun 2025 08:00:00 +0000

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.

Relational databases trained me to think: “What objects do I need, and how are they related?”

Time series databases made me ask: “What measurements am I taking and when?”

This fundamental change in thinking transforms how you approach certain data problems. But when does it make sense to switch?

When relational databases start to struggle

The breaking point usually isn’t query speed—it’s when your database starts experiencing lock contention because you’re hammering it with high-frequency updates while trying to read data at the same time. You’ll know you’ve hit it when:

Dashboards freeze during data ingestion spikes
Concurrent reads and writes start blocking each other
Your “last 24 hours” queries take 30+ seconds
You’re spending more time optimizing indexes than building features

This is where time series databases shine. They’re built for constant writes with occasional reads, not the balanced read/write patterns that relational databases expect. They define the schema on write, which means you don’t have to define the table columns up front.

Here’s the thing about time series data: individual rows are meaningless. One temperature reading or GPS coordinate by itself tells you nothing—unless you’re dealing with real-time snapshots where that single moment actually matters (like the latest stock price or current system status). But for most time series use cases, the sheer volume of those rows will start to tell a story that you didn’t explicitly architect together. It’s actually a perfect database style for machine learning to study.

The mental and data model shift

Working with time series data means letting go of relational context. At first, this feels uncomfortable. You lose the immediate understanding of what each piece of data “belongs to” in a business sense.

But something interesting happens as you adjust: patterns start emerging that you never noticed before. Time becomes your primary organizing principle, and you begin seeing trends, cycles, and anomalies that were invisible when the data was scattered across normalized tables.

Patterns emerge from the data itself rather than from the relationships you designed.

Data Model Transformation

This isn’t just a mental model shift—it’s a fundamental data model transformation. Let me show you what I mean:

Relational data model (SQL):

-- Flights table
flight_id | airline | departure_time | arrival_time | origin | destination
----------|---------|----------------|--------------|--------|------------
AA1234 | American | 2024-01-15 08:00:00 | 2024-01-15 11:30:00 | JFK | LAX

-- Flight Metrics table (with foreign key)
id | flight_id | metric_type | value    | timestamp
---|-----------|-------------|----------|------------------------
1  | AA1234    | altitude    | 28500.0  | 2024-01-15 08:00:00
2  | AA1234    | speed       | 540.0    | 2024-01-15 08:00:00
3  | AA1234    | heading     | 270.0    | 2024-01-15 08:00:00
4  | AA1234    | altitude    | 29200.0  | 2024-01-15 09:00:00
5  | AA1234    | speed       | 560.0    | 2024-01-15 09:00:00

Time series data model (SQL):

-- Single measurement with tags and multiple fields
measurement: flight_metrics
tags: flight_id=AA1234, airline=American, origin=JFK, destination=LAX
timestamp             | altitude | speed | heading
----------------------|----------|-------|--------
2024-01-15 08:00:00   | 28500.0  | 540.0 | 270.0
2024-01-15 09:00:00   | 29200.0  | 560.0 | 268.0
2024-01-15 10:00:00   | 29800.0  | 555.0 | 269.0

See the difference? In the relational world, we’re building entities with attributes and relationships. In the time series world, we’re capturing measurements at specific moments. This shift in data structure changes how you interact with your data.

The time series query states exactly what you mean: give me the average altitude per minute. No pivoting, no CASE statements, no fighting the data model.

Relational SQL:

-- Fighting to get time-based data out of a relational structure
SELECT 
    AVG(CASE WHEN metric_type = 'altitude' THEN value END) as avg_altitude,
    DATE_TRUNC('minute', timestamp) as minute
FROM flight_data 
WHERE flight_id = 'AA1234' 
GROUP BY DATE_TRUNC('minute', timestamp);

Results:
minute                  | avg_altitude
------------------------|-------------
2024-01-15 08:00:00     | 28500.0
2024-01-15 09:00:00     | 29200.0
2024-01-15 10:00:00     | 29800.0

Time series SQL:

-- Direct expression of what you actually want
SELECT 
    time_bucket('1m', time) as minute,
    AVG(altitude) as avg_altitude
FROM flight_metrics 
WHERE flight_id = 'AA1234' 
GROUP BY minute;

Results:
minute                  | avg_altitude
------------------------|-------------
2024-01-15 08:00:00     | 28500.0
2024-01-15 09:00:00     | 29200.0
2024-01-15 10:00:00     | 29800.0

The ORM challenge

The biggest adjustment is the ORM paradigm shift. Whatever your platform, you’re used to thinking in objects and relationships. For this example, we will use C# and Entity Framework.

The ORM way (C#):

// Think in entities and relationships
public class FlightData
{
    public int Id { get; set; }
    public string FlightId { get; set; }
    public List < FlightMetric > Metrics { get; set; }
}

// Query with navigation properties
var flightWithMetrics = context.FlightData
    .Include(f => f.Metrics.Where(m => m.Timestamp > yesterday))
    .FirstOrDefault(f => f.FlightId == "AA1234");

The time series way (C#):

// Think in measurements at specific time points
public async Task RecordFlightMetrics(string flightId, double altitude, 
    double speed, DateTime timestamp)
{
    var point = PointData
        .Measurement("flight_metrics")
        .Tag("flight_id", flightId)
        .Field("altitude", altitude)
        .Field("speed", speed)
        .Timestamp(timestamp, WritePrecision.Ms);

    await _influxClient.GetWriteApiAsync()
        .WritePointAsync(point, "aviation", "my-org");
}

Can You Use an ORM with a Time Series Database?

Short answer: not really, and you wouldn’t want to. ORMs are designed for modeling objects and their relationships using foreign keys and navigation properties, not how the objects evolve over time. Time series data is fundamentally different—it’s measurements over time, not related entities.

Instead of fighting this, embrace the directness. Time series databases give you more control and better performance by working directly with the data model rather than abstracting it through object mappings.

The trade-offs are real, though.

What you lose moving away from ORMs:

Rich object models with navigation properties
Automatic SQL generation and change tracking
Language-integrated queries (LINQ, Criteria API, QuerySets, etc.)

What you gain with direct time series access:

Massive performance improvements for time-based queries
Schema flexibility without migrations
Purpose-built time aggregation functions

For many applications dealing with high-frequency data, the performance gains outweigh the development convenience you lose. Most time series databases also offer language-specific SDKs (like the InfluxDB 3 SDK for C#) and integrate with data collectors like Telegraf for simplified data ingestion.

The reality check

Here’s what I learned: most applications don’t need time series databases. If your primary use case is about managing the current state of an object, or you need consistent views across multiple tables, time series databases are likely not the right tools. If your data volume is manageable and you’re not seeing concurrent read/write conflicts, stick with what you know.

Time series databases make sense when:

High-frequency data ingestion is causing database locks
You’re building something that acts like a “data historian”
Patterns over time matter as much or more than the current values
Storage costs are becoming significant due to data volume

Stick with relational databases when:

Individual records have a critical business context
You need complex queries across different data types
Data volume isn’t causing performance issues

Start with a quick test and hybrid approach

My advice: don’t overthink it. Take your most demanding, high-frequency API endpoint and try routing it to a time series database instead. Set it up in parallel with your existing system and see what happens.

The usefulness becomes clear quickly. Either you’ll immediately see the benefit and start thinking of other places to apply it, or you’ll realize your current approach is working fine.

High-frequency insert pattern – relational approach (C#):

// Instead of this high-frequency insert pattern...
public async Task LogUserActivity(int userId, string action, DateTime timestamp)
{
    var activity = new UserActivity 
    { 
        UserId = userId, 
        Action = action, 
        Timestamp = timestamp 
    };

    _context.UserActivities.Add(activity);
    await _context.SaveChangesAsync(); // This can cause locks under load
}

High-frequency insert pattern – time series approach (C#):

// Try this approach for high-frequency data
public async Task LogUserActivity(int userId, string action, DateTime timestamp)
{
    var point = PointData
        .Measurement("user_activity")
        .Tag("user_id", userId.ToString())
        .Field("action", action)
        .Timestamp(timestamp, WritePrecision.Ms);

    await _influxClient.GetWriteApiAsync()
        .WritePointAsync(point, "analytics", "my-org"); // Non-blocking writes
}

Most real applications end up using both databases. Keep user accounts, orders, and business logic in your relational database; route high-frequency measurements, events, and analytics data to a time series database.

This gives you the best of both worlds: rich relational context where it matters and efficient time-based storage where volume is the challenge.

Making the call

After years of building with SQL databases, I can tell you there’s a clear breaking point. When you start spending more time optimizing database performance than shipping features, that’s your signal.

InfluxDB 3’s SQL support eliminates the learning curve barrier that stopped many of us before. If the problems in this post sound familiar, try it for free to see the difference immediately.

Using Azure Blob Storage for InfluxDB 3 Core and Enterprise

Heather Downing (InfluxData) — Thu, 20 Mar 2025 07:00:00 +0000

Introduction

InfluxDB 3 Core and Enterprise introduce a powerful new diskless architecture that lets you store your time series data in cloud object storage while running the database engine locally. This approach offers significant advantages: you get the performance of a local database combined with the durability, scalability, and cost-effectiveness of cloud storage.

In this tutorial, I’ll show you how to set up InfluxDB 3 Core or Enterprise with Azure Blob Storage as your object store. This configuration is ideal for scenarios where you want persistent storage without managing physical disks, need to access your data from multiple locations or require a more resilient backup strategy.

Prerequisites

Before getting started, you’ll need:

InfluxDB 3 Core or Enterprise installed on your local machine (but don’t run it yet)
An Azure account with access to create storage resources
A terminal or command prompt with the necessary permissions (super user/admin)

Set up Azure Blob Storage

First, we need to set up an Azure Storage account and container to store our InfluxDB data:

Create an Azure Storage account:
- Navigate to the Azure Portal and sign in (requires a subscription and a resource group).
- Create a new Storage account with “Blob storage” as the storage type.
- Under Advanced, make sure a “Hot” access tier is selected for optimal performance.
- Note your storage account name (e.g., influxdb3blobstorage) and select “Go To Resource.”
Create a container:
- Within your storage account, create a new container (e.g., influxdb3-data).
- This container will store the WAL or Parquet files which InfluxDB 3 writes data to.
Get your access credentials:

From your storage account, obtain the storage access key which you’ll use to authenticate InfluxDB with your Azure Blob Storage.
Expand “Security + networking” on the left-hand menu of the storage account (not the container).
Select “Access Keys.”
Copy one of the keys (not the connection string) to use for InfluxDB3.

Start InfluxDB with Azure Blob Storage

Now that you’ve set up Azure Blob Storage, you can configure InfluxDB to use Azure as an object store. You can store your access key in an environment variable for better security.

Open your terminal.
Navigate to where InfluxDB 3 was installed (you have to set your source in order to run it).
Replace the values in the config below with your Azure access key, storage account name and bucket (container) name and run the following:

NOTE: The CLI serve examples below are for Enterprise and include the following parameters not needed for InfluxDB 3 Core:

cluster-id
mode

influxdb3 serve \
    --object-store=azure \
    --node-id=azure01 \
    --cluster-id=cluster01
    --azure-storage-access-key="YOUR_ACCESS_KEY" \
    --azure-storage-account=influxdb3blobstorage \
    --bucket=influxdb3-data

Replace the placeholder values with your Azure storage account name, access key, and container name. The access key should be set inside of a string in quotations.

Write and query data

Once your InfluxDB instance is up and running with Azure Blob Storage, you can write and query data as you normally would. You can interact with your data in several ways, including language client SDKs, API, Telegraf, or CLI. You can use third-party visualization tools as well to read the data.

The database engine runs on your local machine, while Azure provides persistent storage. Since this is a schema-on-write database, you can declare the database name when you write to it. Keep in mind the number of databases, tables and columns available for Core and Enterprise licenses when you craft your commands (for example, only one node is available for Core).

NOTE: Open a separate terminal window for your write/query commands to not interrupt the database engine while it’s running in your original window.

Here’s an example of using the CLI to write data (with line protocol syntax):

influxdb3 write --database=testdb "
cpu,host=prod-server1,region=us-west 
usage_percent=88.2,memory_gb=31.8,disk_used_percent=71.3 1739578205959259001
cpu,host=prod-server2,region=us-east 
usage_percent=87.4,memory_gb=62.1,disk_used_percent=78.9 1739578205959259002
"

Upon success, go to your Azure container to see the file system containing your new WAL file:

influxdb3-data > azure01 > wal > 00000000001.wal And to query that data using SQL:

influxdb3 query --database=testdb "SELECT * FROM cpu LIMIT 10"

You should see:

How InfluxDB uses Azure Blob Storage

When InfluxDB receives write requests, it processes them through the following flow:

Incoming writes are validated, then data is buffered in memory.
Every second (configurable), the write buffer’s contents are flushed to Write-Ahead-Log (WAL) files in object storage (such as your Azure Blog Storage container).
Data moves to a queryable in-memory buffer, where it’s available to incoming query requests.
Approximately every 10 minutes, the contents of the queryable buffer are persisted to Parquet files in your Azure Blob Storage container.

This architecture means:

Your most recent data is served from memory for fast access
Data is persistently stored in Azure Blob Storage
You get durability without the overhead of managing local disks
With InfluxDB3 Enterprise, you get compaction and cheaper storage costs

Multi-node setup with Azure Blob Storage (Enterprise)

One of the powerful features of InfluxDB 3 Enterprise is the ability to set up high-availability clusters. With Azure Blob Storage as your Object store, you can configure multiple nodes to read and write to the same storage:

NOTE: InfluxDB 3 Enterprise Clustering In InfluxDB 3 Enterprise, a cluster is a group of nodes sharing the same object storage that work together to provide high availability and workload distribution. Each node in the cluster requires a unique --node-id while sharing a common --cluster-id. For compaction management, run one node in compact mode to process WAL files into optimized Parquet files. Ingest nodes write data to the object store in their own directories, while compaction nodes consolidate and optimize this data for efficient querying. This separation lets you scale write operations independently from compaction processes, improving overall system performance.

The --cluster-id parameter is required for all new InfluxDB 3 Enterprise instances and must be different from any --node-id in the cluster.
Only one node can be designated as the Compactor.

A basic Enterprise example:

# Node 1
influxdb3 serve \
--node-id=azure01 \
--cluster-id=cluster01 \
--mode=ingest,query,compact \
--object-store=azure \
--azure-storage-account=influxdb3blobstorage \ 
--azure-storage-access-key="YOUR_ACCESS_KEY" \
--bucket=influxdb3-data \

# Node 2
influxdb3 serve \
--node-id=azure02 \
--cluster-id=cluster01
--mode=ingest,query \
--object-store=azure \
--azure-storage-account=influxdb3blobstorage \ 
--azure-storage-access-key="YOUR_ACCESS_KEY" \
--bucket=influxdb3-data

This provides resilience: if one node fails, the other continues to operate with full access to all data stored in Azure.

Who should consider this

Using Azure Blob Storage with InfluxDB 3 gives you the best of both worlds—the performance of a local database engine with the durability and scalability of cloud storage. Your queries remain fast (especially when querying recent data) while your data stays safe in the cloud.

This configuration is particularly valuable for:

Organizations with existing Azure infrastructure
Applications requiring high durability without complex local storage management
Multi-region deployments where data needs to be accessible from different locations
Cost-effective long-term storage for time series data

We hope you’ve found this tutorial helpful! Please share your experiences using InfluxDB 3 with Azure Blob Storage in our community forums or Slack channel.

Download Core or Enterprise to get started. Check out our Getting Started Guide for Core and Enterprise, and share your feedback with our development team on Discord in the #influxdb3_core channel, Slack in the #influxdb3_core channel, or our Community Forums.