Hi everyone.
I set up Internal Historian QuestDB and linked a tag to this storage provider. I can see in the status page that the tag data is being stored successfully.
However, I don’t see this storage provider listed in the Database Query Browser in the Designer.
Am I missing something?
Thanks in advance for your help!
I believe I read somewhere that if you want to be able to read it using Postgres queries that you need to check a box in the settings of the provider. Even then, I believe you'd probably need to set up a separate database connection manually. From Ignition, the historian isn't intended to do manual queries from itself as those should use the built in scripting functions for this like queryTagHistory.
Are the alarm journals and audits going to divorced from the quest dB database and still use something like MSSQL? Will tables like user/roles be intergrated into the questDB or also still in an external dB. Trying to wrap my head around is the integrated historian purely for tag data. Also, will there be a means to import existing SQL historical data into an 8.3 upgrade or will two historians need to be maintained?
QuestDB seems to be a more powerful alternative for the history provider.
I suppose alarms journal and audits stay with sql db...That’s probably why there is only 1 licences for the 2 modules.
That enable to smoothly upgrade existing 8.1 system to 8.3, existing historian for tag data can be unchanged or when you switch to questdb you need to use system.historian.* new function too...
The internal QuestDB historian does not use a database connection to perform it's function. What are you trying to accomplish with database connection?
I wanted to begin playing with the database. I wanted to look at the data outside of ignition, configure replication for high availability, etc. With it being "internal," I have very few methods for interacting with it and determining if the data is good or more advanced features.
In case you didn't notice there's a new set of API calls for the historian
I don't know if this helps you but I noticed this new section so I thought I'd mention it.
We are using QuestDB Embedded, so features available via QuestDB Enterprise, such as high availability, role based security, and tiered storage as not available. We are working on a solution to support synchronizing data using Ignition redundancy, but that is not available at this time.
You can access the internal historian database, in a read only manner, by creating a Postgres connection to the following details:
Connection String: jdbc:postgresql://localhost:8812/qdb
Username: user
Password: ignition
Writing arbitrary data to the internal historian is not a planned feature at this time.
Could you please share a timeline for the Backup and High-Availability features for the new internal database or is this already planned for the 8.3 release? These seem like essential components for a production-ready environment.
The default postgres connection isn't available either, but it looks installable. I'll look into that.
I don't see a setting for the password and username, that seems like a security issue.
Bwah, ha, ha, ha! 
"IA" and "timeline" aren't friends. 
Timeline... When it's done.
I'd still take that over "before it's done" which is what one particular competitor does.
The server is bound to the loopback interface and is read only.
What do you mean by "the default postgres connection isn't available"?
in the meantime to have a redundant quest historian,
we can perhaps use an history splitter with a local quest internal historian for the first connection and a remote historian with gan pointing to the local quest internal historian of the backup gateway ?
There is no choice for PostGres out of the box, I'd need to upload my own JDBC drivers I think.
And though read only is great, some customers want even read access to be limited...
Is this a fresh install or an upgrade? We provide a Postgres JDBC Module, which should be present on a fresh install.
You can try it 
Okay I hear you about not storing arbitrary data. But what about Ignition's own audit event and alarm journal data? Putting that in a high performance first-party historian seems like a no brainer to me. Are you saying that a future 8.3.x version will not make that an option when configuring those systems instead of a database connection?
Fresh install using docker.
You have to modify the ignition.conf file to enable PGwire and restart the gateway to enable the database connection.
