Hi all,
With the new historian currently implemented for QuestDB, are there plans from the Inductive team to build support for TimescaleDB and InfluxDB as well? Or would it make more sense for us to develop these modules ourselves?
Timescale already works, why do they need more support?
The new historian enables aggregation in the database, so you'd be able to use powerchart with aggregation in the db. You'd need a module to actually do those aggregations in the db.
The new historian also doesn't do clustering or redundancy, nor does it do standard durability. It is fast, but at the cost of reliability. It is not a "better" system, just an upgrade to the ailing SQLite internal historian option for people not wanting to use an external database.
1 Like
I'm sorry, I'm not actually talking about the new historian, but about the new historian API. I agree with your statement if you're looking to use an internal historian.
The new historian api is superior to the old historian api in many ways. It will enable tools like influx, questdb, timescaledb to be used in their full power, because you're able to do aggregation on the database itself, instead of always querying the raw data and doing aggregation in Ignition.
Disclaimer: Not my product area, this is not an 'official' company statement.
I believe there are plans to have first class support (whether via first or "second" party modules [1]) to connect to one or more "off the shelf" time series databases such as Timescale/Influx. I have no idea exactly which database(s) we might support, nor when that might happen.
If you need that capability within the next year, I'd say to build the module yourself.
e.g. an industry partnership akin to Cirruslink ↩︎
1 Like
Paul’s comment is correct.
Redundancy will be handled in 2027.2
Support for changing the durability mode will be added in the 8.3.x timeline. We are currently relying on the operating system and hardware for durability.
Considering that Ignition does not implement any database redundancy technology at all, I think adding it to the platform so soon after adding the database itself is quite remarkable.
And the key won't be whether it is handled, but whether it is handled well. If your clients need database redundancy any time soon, plan on deploying a properly redundant external database.
2 Likes
Hi @pturmel
"Soon" isn't the wording I'd use, but I'm definitely on the same page. I know this isn't a simple task, and handling it properly is key. As mentioned here New Historian - QuestDB - #16 by Kyle_Chase1 and New Historian - QuestDB - #34 by Kevin.McClusky we were expecting this in the 8.3 line, not in the new yearly releases 
Of course, we'll provide alternative solutions to help simplify operations.
And by the way, I totally agree on New Historian - QuestDB - #46 by pturmel (like the raison d’être term too)