> These products are built on more than four years of development and powered by the FDAP stack—Apache Flight, DataFusion, Arrow, and Parquet—and delivered on our rebuilt time series database architecture.
So awesome.
Its a bit harder to be quite as merry when the list of things that are enterprise only is so long. I know companies need to pay the bills, & don't begrudge them their decisions, but this still hurts;
> InfluxDB 3 Enterprise adds historical query capability, read replicas, high availability, scalability, and fine-grained security.
Having 72 hour max limit, single instance only, without high availability, and reduced security each seem like really big feature gates to deny the open source edition. Any even mildly serious adopter is probably going to need at least one of these.
I want to stay positive & hopeful & still am, but this feels like one of those really narrow open core strategies that makes me nervous.
So Core isn't intended to be a full historical TSDB. It's more like a data collector, processing engine, data shipper and recent data buffer/DB.
For a full historical TSDB, that's the product we sell. Keeping the two separate gives us the ability to have real open source vs. combining them and requiring a different license that lets us do freemium.
We'll likely have a freemium tier for the commercial product (Enterprise), but that's separate from the open source project.
> InfluxDB 3 Core gives developers a new tool for time series data management—a high-performance recent-data engine optimized for querying the last 72 hours of data. This focused approach enables Core to deliver exceptional performance for real-time monitoring, data collection, and streaming analytics use cases. By optimizing specifically for this pattern, we’ve achieved query response times under 10ms for last-value queries and under 50ms for hour-long ranges.
The limitation of 72 hours of data is a bit disappointing. There are use cases that don't require 50ms query response times, but instead need longer on-prem storge. InfluxDB 1.X and 2.X supported these well. Would it be possible to reduce query performance and extend data retention?
Is there any guidance on a planned EOL for InfluxDB 1.X and 2.X once Core reaches GR?
It's a constraint that we could relax over time, but for now we wanted to limit the scope so we can focus on the recent data. We're also considering a free tier of Enterprise for at-home use cases (i.e. non-commercial hobbyist).
As for EOL on previous versions, we don't have anything planned at the moment. We're partnered with AWS on their hosted versions of InfluxDB 2.x OSS so I expect that to continue for quite some time.
Can you say more about your use case?
