I actually went through pretty much the same exercise recently, because the old Home Assistant Community Add-on for InfluxDB is deprecated.
The confusing part is that there are actually two separate things involved: the database itself, and the Home Assistant integration that sends data to the database.
The built-in InfluxDB integration is not the database. It’s the Home Assistant side that writes entity data to an InfluxDB instance. You therefore still need an InfluxDB server somewhere.
The old hassio-addons/addon-influxdb basically provided that InfluxDB server as an HA add-on. So the setup was roughly:
Home Assistant
|
| InfluxDB integration
v
InfluxDB
|
v
Grafana
The various InfluxDB 2/3 projects you found are, as far as I understand it, mostly different ways of running the InfluxDB server inside HA. They don’t replace the HA integration itself. So yes, in those cases you would normally still use the built-in InfluxDB integration to send the data.
I initially considered just moving to one of those newer InfluxDB add-ons, but I wasn’t particularly enthusiastic about moving from one add-on that is becoming obsolete to another community-maintained InfluxDB add-on and hoping it remains maintained.
That’s when I started looking at VictoriaMetrics.
For my use case, VictoriaMetrics turned out to be a very nice alternative.
Instead of using the HA InfluxDB integration, I use the built-in Prometheus integration in Home Assistant:
prometheus:
Home Assistant exposes its entities through a Prometheus-compatible endpoint, and VictoriaMetrics scrapes that endpoint and stores the data.
So my setup is now:
Home Assistant
|
| Prometheus exporter
v
VictoriaMetrics
|
| Prometheus API
v
Grafana
And the nice part is that I don’t need a separate Prometheus server. VictoriaMetrics can do the scraping and storage itself.
I initially wondered about that too: normally you’d expect a Prometheus collector/server in between. In this setup VictoriaMetrics effectively fills that role.
For example, one of my HA sensors shows up in VictoriaMetrics as:
homeassistant_sensor_temperature_celsius{
entity=“sensor.brink_renovent_temperature_from_indoors”
}
Other entities get appropriate metric names, e.g. power, humidity, CO2, etc.
The one thing that is not a drop-in replacement is the Grafana side.
My old dashboards were using InfluxQL, for example:
SELECT mean("value")
FROM "sensor"
WHERE ...
With VictoriaMetrics I have to use PromQL instead.
So I did have to convert my existing Grafana dashboards.
However, that turned out to be much easier than I expected. I’ve now converted several dashboards for my WTW/ventilation, indoor climate, airco, Synology and TP-Link Deco setup, and everything is working nicely.
I also decided not to migrate my old InfluxDB history. I simply started collecting new data in VictoriaMetrics and rebuilt the dashboards. I’m keeping the old InfluxDB around temporarily as a fallback, but once I’m happy with the new setup I’ll remove it.
So if I were starting from scratch today, for my particular use case I’d probably go with:
Home Assistant
|
| built-in Prometheus integration
v
VictoriaMetrics
|
| Prometheus datasource
v
Grafana
Rather than installing another InfluxDB add-on.
That said, if you specifically want InfluxDB, the built-in HA InfluxDB integration is still perfectly valid — just remember that it’s the client/exporter, not the database itself.
And yes, I would consider VictoriaMetrics a very good replacement for what I was using InfluxDB for. The biggest migration job is simply converting the Grafana queries from InfluxQL to PromQL.
One small warning though: there are multiple VictoriaMetrics HA projects/add-ons around. I initially looked at the older VictoriaMetrics-Community/homeassistant-addon-victoriametrics, but I ended up using the newer VictoriaMetrics Home Assistant App. So make sure you don’t accidentally mix documentation for the older add-on with the newer App.
For me, the move has actually been a very positive one so far. 
