v2 is perfectly fine and doesn’t have the limitations v3 has.
First of all, I was caught by surprise with zero lead time on the sunset of the influxdb add-on. The other surprise was the “popup” where I managed to not click on the button ;-).
I am right now looking into migrating over to Timescale. It is available as an “App” but you can also run it standalone for scale-out purposes. Inside it’s Postgres. It’s also supported by Grafana as a “Postgres” datasource.
But there are some caveats; the biggest is integration - unlike influxdb you configure it via the “recorder” option in the configuration.yaml. That moves your recorder into Timescale - no more history in SQLite3! This is fine as long the Timescale DB is up and running, but in case of issues with the DB / Add-on your history is partially gone.
Therfore, I have come up with a small, local HA Add-on in python. That allows me to use SQLite3 / recorder as stable datasource. I pull data “as is” via a job from SQLITE into Timescale and do the rest in Postgres. The piece of python coding makes the solution “failsafe” - I have tested all kind of “desasters” today.
Data migration is still an open topic; I’ll look into it over the next days / weeks.
Personally, I feel this is the route for me to go. Just wanted to share the idea in case you are also looking for alternatives. For me the biggest advantage is - it’s all SQL - I never got too familiar with Influx Queries. And it makes another migration easier.
In case Postgres goes EOL, I keep the mechanism, exchange the database and copy over my analytics schemas.
I have been following this topic from the beginning and also chiming in as a victim of this “rug-pull”. Abandoning InfluxDB is quite a disaster for me. I am not using it for any dashboards and I use Grafana only as a “frontend” to explore my data. But keeping indefinite data of everything is highly important to me.
Thus far sadly no real solutions fits yet:
- Abandoning it completely in favor is recorder as this site suggests: clearly a non-starter
- InfluxDB3 looks to have a huge amount of issues:
- 72h maximum query range is an absolute non-starter. Whats the point of InfluxDB then? I am using this for huge aggregate data analysis over multiple years (e.g. W/C over the years)
- Not really open source any more, requires a “personal license”
- Other issues mentioned above (e.g., only 2 CPU cores, undocumented query rate lints)
- Huge resource hog
- VictoriaMetrics: New query language and if I understand correctly, only supports float64 … all my data that uses strings etc will be lost.
This is really a big bummer 
There seems to be supported migration paths from Influx > VictoriaMetrics
I don’t have time to review and see if they’re usable with the HA App now, but let’s keep our fingers creossed.
Are they going to be useful if the data isn’t there to migrate from?
It would appear an unfortunate case of poor timing, the removal tool being abruptly deployed before the migratory one was offered as an alternative for people to use.
I’ve not decided on which route to go. I don’t see the need to hurry. The installed influxdb v1 does work for me. But I want to keep my history data.
You better hope you can restore ypur data from your backup too.
A sorry confluence of embarrassment.
I think I’ll go buy a lottery ticket. Not everybody will get three times unlucky.
I’ve not decided on which route to go. I don’t see the need to hurry. The installed influxdb v1 does work for me. But I want to keep my history data.
Also thinking about this for now but the persistent warning annoys me. Interestingly it can’t be “Ignored” (as any other similar items), see below:
Are you able to or you don’t mind?
(I am using these persistent notifications are reminders that need immediate attention … so while I dont want to dismiss this completely, I don’t it to clog my limited attention)
Whoa. I nearly clicked the repair without realizing it would nuke Influx entirely. That would have broken quite a few things. I have a number of node red flows that leverage Influx. Some sort of migration path would be very helpful. P.S. Worth saying, I am grateful for all the hard work that goes into this.
I ran into this issue as well, as the message popped up after restarting Home Assistant.
Glad I haven’t clicked “OK”, so InfluxDB v1 is still running fine. But I’m interested in a successor solution. I’ve used InfluxDB together with Grafana and I do use a lot of Grafana dashboards with history up to 5 years. I also use transform and math features inside Grafana.
Has anyone finally managed a migration to VeronicaMetrics? Does Grafana with transform and math features also work? Is any migration how-to available?
Is InfluxDB v1 EOL? it received a feature update about a month ago : InfluxDB v1 release notes | InfluxDB OSS v1 Documentation
But the influxDB version inside the app has been stuck at 1.8.10 since 2021. InfluxData had a gap of a few years with no updates on the v1 version, but the picked it up again in late 2024 ( InfluxDB v1 release notes | InfluxDB OSS v1 Documentation ) , and have been updated it ever since.
So there is hope that someone picks up maintaining this app and update influxdb to 1.13. This will drop support for 32 bit platforms tho, but it should save most of us.
I get why this addon is discontinued/deprecated but that it was rolled out this way is downright embarrassing.
In my case, though, I don’t think I’ve looked at my Grafana stuff in literally years, so I think I will just be removing it.
I did browse around on on influx website yesterday and I did the same discovery. There has been a resent update to InfluxDB 1. I wonder if there are other dependency changes that has been made way back and they’ve decided not to update becase it would not run well with Pi and HA hardware.
Would be nice to get some clearafication on this.
I clicked “submit” 
All datas are lost 
First time for me that even a database will be deleted without questioning
My guess is that its either the warning InfluxData slapped on the 1.11 update, that its a big update and you are advised to make backups and test in parallel first etc, and that they dropped support for 32 bit platforms. So to support Pi 2/3 setups, or others that installed the 32 bit OS, the maintainer decided to stick with the (now ancient) InfluxDB v1.8.10
@alkissack and others, just went through this exact migration a few days ago after hitting the same repair message. You don’t have to give up InfluxDB/Grafana, a full v1 → v2 migration on HAOS is genuinely doable and preserves your historical data.
Don’t click Submit on that repair dialog, that deletes your v1 database, and you’ll want it as your source/reference during migration.
Short version of what worked for me:
- Take a full backup first.
- Install the community
danieloldberg/addon-influxdbv2add-on (separate repo, still active/maintained). - Use the add-on’s own README for the export/import steps (
influx_inspect exporton v1 →influx writeinto v2) This worked cleanly for ~6 months of data (which was all my data, note if you have years it’ll take a while to export and write and there’s little feedback I worried it was hanging but then could see data was populating by running the odd query through the UI on a key field so was reassured and the UI was friendlier than v1 so wasn’t hard to do) . - Watch out for two gotchas that cost me real time: HA can silently keep using an old config entry instead of your updated
configuration.yaml(delete the entry under Devices & Services and let it regenerate), and if you’re converting Grafana dashboards from InfluxQL to Flux,aggregateWindow()mislabels time buckets by default unless you addtimeSrc: "_start".
I wrote up the fuller version with more detail here (InfluxDB | Migrate from v1.8 to 2.0/3.0).
Re: v3 not yet, in my view. No official migration tool exists, and if you’re on HAOS the only path right now is a very new single-maintainer community add-on. v2 is stable, actively maintained, and the sensible stop for now. [Flux takes some learning and getting your head around for Grafana]
One more thing worth knowing: HA is also removing the YAML-based InfluxDB connection config (host/port/token/etc.) in the 2026.9 release, so even if you’re not ready to fully migrate to v2 yet, it’s worth being aware this is coming separately from the repository/add-on issue above.
Doubt that, since it’s the same person that made the announcement that 32-bit is no longer supported over a year ago.
Restoring from backup did not work for me because it also requires the app to be downloaded. But downloading the InfluxDB database to my PC from the backup worked. Now I only need to figure out whether it is possible to import the InfluxDB data into VictoriaMetrics and continue the existing time series.
Then the first action step would be to just clone the repo, change the InfluxDB, telegraf and kapacitor versions and see if it builds.
I dont know enough about HA to have any idea how to change the repo ‘underneath’ an installed app, so keep the data volume intact.
Testing is made extra complicated by the fact that you cant just try it, because a restore wont work coz the ****** original app repo was pulled! Something like this should never break restores from backups!