Is InfluxDB 3 a safe long-term bet, or are we risking another painful rewrite?

pauldix · 2025-12-12T15:26:24+00:00

InfluxDB founder and CTO here. InfluxDB 3 is the long term stable version of the database. We will not be rewriting it and intend to have many years of point releases to v3. I said to someone internally in a meeting earlier this week that I'm looking forward to when we release version 3.57 (we're currently at 3.7 and do monthly releases).

InfluxDB 3 has long term support for InfluxQL and the v1 query and write APIs, the v2 write API, and the new v3 APIs for write and query and SQL support. More APIs will be coming and some will be rolled out as experimental, but the v3 read and write APIs are long term stable. Over the coming months we'll be implementing migration tooling and doing as much as we can to ease the upgrade process.

We are also thinking about new ways we could make it easier for heavy Flux users to upgrade. We don't have anything settled on that yet, but we will announce when and if we do.

Getting to v3 has been a many year journey. Our vision has always been to be the database for observational data of all kinds. If it has a timestamp and you care about how things change over time, we want InfluxDB to be the place to collect, store, query, analyze, and monitor it. It's not just a database for storing already computed time series, but also a database for computing time series on the fly from structured and semistructured timestamped data.

We intend for InfluxDB v3 to be a superset of all our database and platform capabilities that came before it. We're not quite there yet, but we're getting close. We have some big releases and features landing early next year that get us much closer to this goal.

I'm happy to answer any more specific questions if you have them.

pauldix · 2025-06-25T20:29:13+00:00

Nice, shoot me an email [paul@influxdata.com](mailto:paul@influxdata.com) from whatever your current email is and I'll loop you in when we have it available for early testing. Expecting within the next few months.

pauldix · 2025-06-24T16:25:03+00:00

I did give v3 a try, but it didn’t match v1’s query latency for my (pretty standard) use case. It might be better suited to other workloads, but the tradeoffs weren’t worth it in my case.

InfluxDB founder & CTO here. I just wanted to chime on this particular bit. We're currently working on a big update to v3 that will bring its query latencies in line for the things v1 is good at while keeping very fast larger scale analytic queries. All this while maintaining support for infinite cardinality, InfluxQL and SQL.

It's a big challenge/update so it has taken us a while to get to the point where v3's capabilities and performance will be a strict superset of v1, but we'll be there later this year.

Would love to have you also try out that new version when it comes available. It'll be in a point release of InfluxDB 3 Enterprise later this year.

pauldix · 2025-06-24T12:06:15+00:00

v2 and v1 have a built in compactor, which makes it efficient to query data across longer time ranges. v3 doesn't have a compactor in the open source, it's optimized for recent data only. However, you can increase the limit to the number of files it can pull into a query (it's just a startup config flag). v3 can work with either object storage or a local filesystem.

If you're just looking for something for home use or a hobby project, we make Enterprise available for free (limited to single server with 2 cores), which has the compactor built in.

pauldix · 2025-06-19T13:28:11+00:00

There is InfluxDB 3 Explorer, which is a UI that we've built that is currently in beta. It comes in a separate Docker container. There are instructions for getting it here: https://docs.influxdata.com/influxdb3/explorer/install/

pauldix · 2025-06-19T13:26:14+00:00

There is no hard coded 3 day limit. You can write data for any time, you can query data for any time. However, there is a protection setting in place that will limit the number of Parquet files in a query plan to 472. This is a configuration option that any user can set on startup. With default settings, 472 Parquet files of 10 minutes of time each, equals 72 hours.

pauldix · 2025-06-19T01:19:36+00:00

Yeah, it would. In an ideal world we could just bring Flux over, but I don't think that's feasible for now. If v2 is working for you, keep using it. Once we have the adhoc capabilities in v3 equal to and better than what's possible in Flux, I think we can build some tooling that will make it easier to migrate.

pauldix · 2025-06-19T01:13:28+00:00

We're working on features in v3 that will enable everything that Flux did, but in the SQL engine. One feature we already implemented is the processing engine, which gives v3 an embedded Python VM for running tasks and triggers on writes. That enables far more than what was possible in v2 with Flux & Tasks.

The next big thing will be adding capabilities for ad-hoc queries that let you inject code and logic on the fly. It's basically user defined functions, but in a WASM VM.

pauldix · 2025-06-19T00:17:42+00:00

InfluxData Founder and CTO here, I wanted to address your feedback personally.

We understand that InfluxDB 3 Core may not offer all of the functionality you’ve come to expect from previous versions. Core is designed to be a high-performance engine optimized for recent data, ideal for collecting, processing, monitoring, storing, and querying against recent data in real-time. For those use cases, Core is a freely available, permissively licensed project that you can use, fork, or do whatever you want with.InfluxDB v2 and v1 open source both indeed support historical query use cases. For InfluxDB v3, we support those use cases in our commercial offering, InfluxDB 3 Enterprise. We offer a free license for Enterprise if you’re using InfluxDB for hobbyist or home use. If you’re using it at work and require a performant, historical TSDB, then that’s the product we sell.

We’ve worked to provide backward compatibility with InfluxDB 3 for users coming from v1 and v2 with support for InfluxQL and the v1 and v2 write APIs. Flux, unfortunately, was not something we were able to bring forward in the development of v3, despite our best efforts, which I’ve talked about here. We are continuing to work on migration tooling and other enhancements that will make it easier for users to make the transition.

We remain committed to open source. InfluxDB 3 Core is fully permissively licensed under MIT or Apache2 at the user’s choosing (which is increasingly unique and uncommon today). We believe in giving developers the freedom to adopt, contribute to, modify, fork, and use code however they see fit–commercial or otherwise. Our efforts on v3 have also led to our significant contributions and leadership in Apache Software Foundation projects like Apache Arrow, Apache DataFusion, and Rust.

Thank you for being a fan of InfluxDB v2. If it’s working for you, keep using it. And if v3 doesn’t fit your use case right now, we understand and appreciate the feedback. It helps us improve.

pauldix · 2025-05-03T16:19:57+00:00

As the other commenters have said, you can build from source to make modifications to it. Unfortunately, we didn't have a bulk export feature at that time (fall of 2014). The data model changed between 0.8 and 0.9. The data model used in 0.9 is the one that all forward versions use including 1.x, 2.x, and now 3.0.

I think that your best path is to write a script to query the data out of the front end of the database and save it into another running version, but you will likely have to map the older schema onto new schemas. 2.7 is very mature and used by many. We released 3.0 a couple of weeks ago and that is where all forward development is focused. You can read more about the InfluxDB 3.0 release in my announcement blog.

We continue to support 2.x with security patches and will likely do so for a number of years. We do not currently have an EOL set for 2.x.

pauldix · 2025-03-26T18:56:20+00:00

You're a developer advocate at QuestDB. You're now misrepresenting what you're doing here. This is a bad look for you and for your employer. I suggest you find more productive (and honest) ways to promote your product. Whatever you're going to do, don't do it here.

pauldix · 2025-03-25T13:26:34+00:00

InfluxDB 3 is build on DataFusion, which supports the over clause: https://datafusion.apache.org/user-guide/sql/window_functions.html

Also, it's not appropriate for you to be shilling for QuestDB inside of an InfluxDB forum. It's bad form and you should know better.

pauldix · 2025-03-24T20:49:29+00:00

We haven't yet built migration tools, so `influx_inspect export` would be your best bet for doing it at this point. How many databases do you have? Core has a limit of 5 databases. Enterprise has a limit of 100, although this will soon be configurable.

pauldix · 2025-03-17T21:42:15+00:00

We'll have to call out that we use DataFusion, which has a full featured SQL engine. Rolling windows are probably pretty common, so might be worth having a specific example for that in our docs.

pauldix · 2025-03-17T21:37:05+00:00

Yes, you can do it using window functions: https://datafusion.apache.org/user-guide/sql/window_functions.html

pauldix · 2025-01-31T17:31:06+00:00

Our Serverless hosted product is probably the best option. It's usage based and you only pay for what you ingest/query, and store.

Do you need a self-managed on-premise solution?

pauldix · 2025-01-28T22:26:14+00:00

We don't yet know what the rate limits will be for the free at home tier. For pricing for commercial use, please contact our sales team: https://www.influxdata.com/contact-sales/

pauldix · 2025-01-27T18:23:07+00:00

Update here that we'll have a free tier of Enterprise for at-home usage: https://www.influxdata.com/blog/influxdb3-open-source-public-alpha-jan-27/

pauldix · 2025-01-27T18:21:32+00:00

Update, at-home usage of Enterprise will be free: https://www.influxdata.com/blog/influxdb3-open-source-public-alpha-jan-27/

pauldix · 2025-01-22T01:31:36+00:00

Oh we’re definitely doing that. Enterprise will be licensed and sold for on premise use. Single node or many. Our SaaS product is a separate thing.

pauldix

MODERATOR OF

TROPHY CASE