Yes, the architecture I posted would have Store & Forward built in on the Remote Historian. (Previously called the Remote History Provider.)
Gateway 1 (left): Remote Historian. Includes S&F, so it’ll store on network disconnect or congestion, and forward when things return to normal.
Gateway 2 (right): Internal Historian - QuestDB.
Michael - As you said, if you’re just using a local historian on a single Ignition Gateway, there’s no S&F (and no need for S&F).
I hope this helps!
Hi All,
Is it possible to continue using the historical data that has been collected with a beta installation after updating to the final version?
Or is there a way to back up the data and restore it in a new installation?
Just going to give my opinion here, so take it with a grain of salt, but these beta versions shouldn’t be used for anything in production, so I wouldn’t guarantee that it’s possible except for upgrades on the same installation. I’ve seen mention of being able to backup/restore data at some point, but not sure when that functionality will be finalized.
In short, the data you’ve collected shouldn’t matter, as these beta versions should NOT be used for anything production EVER.
Apologize if this has been answered already; I’ve yet to see it.
Am I correct in thinking that the 8.3 QuestDB will only be available to Tag History and not for specific data writes such as Transaction Groups or scripting? Can you query against it?
I link a lot of SQL tables to Microsoft Excel; is this available through the QuestDB?
Basically, no. Continue using real databases for such tasks. See Paul's Comment #31 above for the Quest Historian's «raison d'être».
bit out of topic, but, if i use ignition 8.3 with redundant capability, is the embedded questDB will automaticly redundant as well, or is it available on the master only ? or do i need to set up another questDB server ?
I think there is no redundancy with the new integrated historian.
Correct, though it is planned.
You can query against the internal QuestDB historian by setting up a postgreSQL connection. This also requires 2 extra Parameters in the ignition .conf file. Gateway and Gateway Network Parameters | Ignition User Manual
Note that this port is bound to localhost--it is not reachable by systems outside that gateway machine.
After setting up a proxy, it is 
Are there any information regarding the data type limitation, in particular strings. Are strings limited to a specific amount of chars?
Would also be great to understand if QuestDB is also the standard historian in the edge gateway
Another question.
Can the systems be setup to use a splitter to a non-quest historian?
IE. HIST_SPLITTER to LocationGateway - QuestDB Historian and EnterpriseHistorian - SQL Server Historian?
I see, so its useless to use embedded historian with redundant server, since it will lose data while the master server crashed or problem. I still need to use minimum 3 servers for redundant, which is cost a lot for my customer.
I don’t see any special limits we’re placing on the length. QuestDB limits varchar fields to 268MB, with a total column size limit of 218TB. Obviously your disk size will limit things too.