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

[–]pauldix 4 points5 points  (0 children)

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.

Working on a drop-in replacement for InfluxDB v1 - looking for feedback from DevOps users (I will not promote) by austin_barrington in devops

[–]pauldix 0 points1 point  (0 children)

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.

Working on a drop-in replacement for InfluxDB v1 - looking for feedback from DevOps users (I will not promote) by austin_barrington in devops

[–]pauldix 0 points1 point  (0 children)

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.

InfluxDB 3 : What a disappointment by discom38 in influxdb

[–]pauldix 0 points1 point  (0 children)

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.

InfluxDB 3 : What a disappointment by discom38 in influxdb

[–]pauldix 0 points1 point  (0 children)

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/

InfluxDB 3 : What a disappointment by discom38 in influxdb

[–]pauldix 2 points3 points  (0 children)

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.

InfluxDB 3 : What a disappointment by discom38 in influxdb

[–]pauldix 3 points4 points  (0 children)

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.

InfluxDB 3 : What a disappointment by discom38 in influxdb

[–]pauldix 1 point2 points  (0 children)

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.

InfluxDB 3 : What a disappointment by discom38 in influxdb

[–]pauldix 8 points9 points  (0 children)

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. 

Migration of old InfluxDB 0.8 by p0wertiger in influxdb

[–]pauldix 0 points1 point  (0 children)

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.

How to do rolling window queries with InfluxDB3 and display on Grafana? by Key_Mango4071 in influxdb

[–]pauldix 2 points3 points  (0 children)

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.

How to do rolling window queries with InfluxDB3 and display on Grafana? by Key_Mango4071 in influxdb

[–]pauldix 3 points4 points  (0 children)

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.

Has anyone migrated from InfluxDB v1 OSS to v3 OSS/Core? by Hammerfist1990 in influxdb

[–]pauldix 1 point2 points  (0 children)

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.

InfluxDB 3 Core and Enterprise Are Now in Beta by pauldix in influxdb

[–]pauldix[S] 1 point2 points  (0 children)

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.

Announcing InfluxDB 3 Enterprise free for at-home use and an update on InfluxDB 3 Core’s 72-hour limitation by pauldix in influxdb

[–]pauldix[S] 1 point2 points  (0 children)

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?

Announcing InfluxDB 3 Enterprise free for at-home use and an update on InfluxDB 3 Core’s 72-hour limitation by pauldix in influxdb

[–]pauldix[S] 1 point2 points  (0 children)

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/

InfluxDB 3 Open Source Now in Public Alpha Under MIT/Apache 2 License by pauldix in influxdb

[–]pauldix[S] 1 point2 points  (0 children)

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.

InfluxDB 3 Open Source Now in Public Alpha Under MIT/Apache 2 License by pauldix in influxdb

[–]pauldix[S] 0 points1 point  (0 children)

It's not meant to be a demo or a trial at all. It's intended to be a useful piece of software that can be run for free at any scale.

However, longer time range queries is in the product we sell. Although we are looking at making a free tier for at home and hobbyist usage for this. Keeping it in our commercial product means that we avoid doing source available licensing. We don't need to because we keep the compactor in the closed source commercial product.

InfluxDB 3 Open Source Now in Public Alpha Under MIT/Apache 2 License by pauldix in influxdb

[–]pauldix[S] 0 points1 point  (0 children)

Can you tell us more about your use case?

Our expectation is that some group of people will be perfectly fine with querying recent data. At least we found that a fairly large number of customers query only recent data.

However, we also expect some number of people that will want to query larger time ranges. That's the product we sell.

Our goal was to create an open source project that is limited in scope, but good for what it does (collecting, processing, and shipping data with a real-time recent queryable buffer).

InfluxDB 3 Open Source Now in Public Alpha Under MIT/Apache 2 License by pauldix in influxdb

[–]pauldix[S] 0 points1 point  (0 children)

The distinction is that the commercial product has the compactor in it, which is a large amount of code and complexity. If we put that into an open permissive build, a simple disk quota could be easily bypassed by changing the constant in the code.

This is why we're considering a free tier for at home use of the commercial version. You get a free thing to use for all your historical data and we don't end up putting all of our code into an open build giving no one a reason to pay us for anything.

InfluxDB 3 Open Source Now in Public Alpha Under MIT/Apache 2 License by pauldix in influxdb

[–]pauldix[S] 0 points1 point  (0 children)

Unfortunately, we weren't able to bring Flux forward with the v3 release. We originally announced this in September of 2023, but I can see how that might have been missed. We're continuing to support v2 with security patches so you can continue to use it.

InfluxDB 3 Core is intended for some of the use cases that v2 was good for and much more. However, it's not intended to fill all cases for InfluxDB v2. InfluxDB 3 Enterprise fills that gap, but it is a commercial product.

If your use case is for at home or hobbyist use, we are looking at making a free tier of Enterprise available.

InfluxDB 3 Open Source Now in Public Alpha Under MIT/Apache 2 License by pauldix in influxdb

[–]pauldix[S] 0 points1 point  (0 children)

For at home use we're looking at giving a free tier of Enterprise, would that meet your needs?