InfluxDB Had Open Storage. Its New Engine Walks Away From It.
InfluxDB shipped version 3.11 today. Paul Dix, InfluxData's CTO and co-founder, called it "probably the biggest release we've shipped since 3.0 in April 2025," and described it as "the culmination of almost a year and a half of work that I've led with the help of the database team." It ships with two headline capabilities: a new storage system that handles wide and sparse schemas, and bulk import and export via Apache Parquet.
That second one is worth stopping on, because it's easy to read past it as a minor interoperability feature. It isn't. It's a quiet admission about what changed underneath.
The part that doesn't add up, until you look closer
Here's the detail that makes this release interesting rather than routine: InfluxDB 3 already stored data in Parquet. That's been true since the 3.0 rewrite, built on Rust, Apache Arrow, and DataFusion, with Parquet as the persistence format on object storage. It's in InfluxData's own architecture documentation, which describes the storage engine persisting data to Parquet files in object storage. It was, genuinely, an open, columnar, industry-standard storage format.
So why does a database that already stores Parquet need to ship "bulk import and export via Parquet" as a flagship feature? Dix says it's "a feature we've wanted to add to InfluxDB since 2016." You don't build an import/export bridge to a format you're already natively stored in. You build one when you've stopped being natively stored in it.
That's exactly what happened.
What's actually shipping: a new proprietary file format
The announcement post describes the new storage system in terms of capability. InfluxData's Enterprise release notes describe it in terms of implementation. Here's the 3.9.0 entry, where this engine first appeared:
"Includes a new columnar file format (
.ptfiles), automatic Parquet migration with hybrid query mode, column families for efficient wide-table I/O, and bounded compaction."
And, from the 3.11.0 release notes, the line that matters most:
"If your cluster uses the upgraded storage engine (the default for new clusters, or after running the storage engine upgrade with
--upgrade-pacha-tree), data written in the new.ptfile format is also unreadable by 3.9.x."
Unreadable by the previous version. That's not a tuning change to an existing format. That's a new, InfluxDB-specific file format, replacing Parquet as the format data is actually written in, with an automatic migration path to move existing Parquet data into it. Parquet doesn't go away. It becomes the format you convert to when you want to get your data back out, an export target rather than the home your data lives in day to day.
Worth noting how deliberate the rollout is. The .pt format landed in 3.9.0 in April 2026. In 3.11.0, per the release notes, "the upgraded storage engine is now the default: New clusters are created on the upgraded storage engine with no opt-in flag required." This is a planned multi-release migration, not a surprise.
To be fair to InfluxData: the engineering reason is real. Wide and sparse schemas, tables with hundreds of columns where most rows only populate a handful of them, are a documented, longstanding pain point in Parquet-based columnar stores. InfluxDB's own schema design docs spend real space warning users about schema shape. The 3.11 announcement says the release "expands schema flexibility with support for thousands of tables and millions of columns, while efficiently handling ultra-sparse datasets where only a small fraction of fields may be populated at any given time." Those are legitimate, valuable goals, and a year and a half of engineering aimed at them isn't a small undertaking. This isn't a cynical move. It's a team solving a real performance problem the way performance problems often get solved: with a purpose-built format that does one job better than a general-purpose one can.
But it's still a trade. And it's worth being precise about which way the trade runs.
Being precise about what has and hasn't happened
The strong version of this argument would be that InfluxDB has abandoned Parquet. That's not what the release notes say, and it's worth getting right.
Three qualifications. First, the upgraded engine is the default for new clusters, but existing Parquet clusters stay on Parquet until an operator explicitly opts in with --upgrade-pacha-tree. Second, migration includes what the release notes call "hybrid query mode," so a cluster mid-migration can still read its existing Parquet files. Third, Parquet remains fully supported as both an import and an export format, and the 3.11 release expands that: influxdb3 import upload now accepts an object store URL as a source alongside a local directory.
So nobody's data is stranded today, and nothing is being taken away from existing deployments. What changed is the default. New clusters, and any cluster that upgrades to get the performance work, write .pt files rather than Parquet.
That's the direction of travel, and it's the part that matters for a decision you'll live with for years.
The trade: performance, paid for with portability
For most of InfluxDB 3.x's life, "your data is in Parquet" has been a real, load-bearing part of the pitch. Open format, no lock-in, query it with any tool that speaks Parquet if you ever need to. That claim gets weaker with every cluster that moves to the new engine. The data isn't sitting in Parquet anymore. It's sitting in .pt files that only InfluxDB can read, with Parquet available as something you export to when you need it, not something your data natively is.
That's not a criticism of the performance work. It's a description of what "open storage" now means for a 3.11 deployment on the new engine: it means you can get your data into an open format when you ask for it. It doesn't mean your data lives in one.
Those are different claims, and the difference is exactly the one that matters when you're deciding what to build a storage layer on top of. A database where the working format is proprietary and Parquet is an export button is a database you can leave, eventually, with some friction. A database where Parquet, or an equally open and equally standard format, is the actual native on-disk representation is a database you were never locked into in the first place.
The friction is not hypothetical. An export is a job you have to run, on data volumes that may be enormous, producing a second copy you need somewhere to put. Native Parquet means pointing another engine at the files that already exist.
Why this keeps happening
This isn't really a story about InfluxDB. It's a story about the tension every fast database eventually runs into: general-purpose open formats are good at being open, and purpose-built proprietary formats are good at being fast for one specific workload. Sooner or later, a team chasing the next order-of-magnitude performance win reaches for the second one, because it's usually true that a format built for exactly your access pattern will beat a format built to be readable by everyone.
The honest answer isn't that this trade is always wrong. It's that it's a trade, and it's worth knowing which side of it your database is on before you build years of data onto it. InfluxDB just told you, in its own release notes, which side it's choosing for the workloads that need real performance.
That's a decision worth making on purpose, not one worth discovering the day you try to read your .pt files with something that isn't InfluxDB.
Arc is a columnar analytical database that stores your data in open Parquet, natively, as the actual on-disk format, not as an export target. No proprietary file format, no migration required to get your own data back. See how Arc compares.