# QuestDB official documentation **URL:** \ **Category:** Ignition\ **Created:** [August 22, 2025, 6:38pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124 "2025-08-22T18:38:04Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![wfiller](https://avatars.discourse-cdn.com/v4/letter/w/2bfe46/32.png) [@wfiller](https://forum.inductiveautomation.com/u/wfiller)\ **Post date:** [August 22, 2025, 6:38pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/1 "2025-08-22T18:38:04Z")
Is there any official documentation on QuestDB such as setting up a connection when installed on localhost. I realize it’s time series and non-relational. Does it have a web interface or did they leave it out since it is embedded? It is unclear to me what username, password, and drivers to use but I have found that postgress works on other forum topics. ---
**Author:** ![wfiller](https://avatars.discourse-cdn.com/v4/letter/w/2bfe46/32.png) [@wfiller](https://forum.inductiveautomation.com/u/wfiller)\ **Post date:** [August 29, 2025, 5:46am UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/2 "2025-08-29T05:46:19Z")
Crickets. Installed ignition-8.3.0-rc1 and testing the Core Historian which looks like Quest DB under the hood. Still not much documentation on purging stale tags or any kind of database management interface. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 29, 2025, 12:24pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/3 "2025-08-29T12:24:52Z")
There isn't. There's a comment on one of the topics about enabling the PostgreSQL-like external port, but everything about this is an internal implementation detail. It is not intended to be managed externally. Ergo, not documented. ---
**Author:** ![wfiller](https://avatars.discourse-cdn.com/v4/letter/w/2bfe46/32.png) [@wfiller](https://forum.inductiveautomation.com/u/wfiller)\ **Post date:** [August 29, 2025, 3:23pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/4 "2025-08-29T15:23:24Z")
Thanks for the response. Is there any mechanism to delete stale/obsolete tags? When history gets enabled/disabled on a particular tag will it re-combine with the old history or is it lost? I’m really familiar with the table structure when using sql historian. I’m just trying to relate it to that, like the ‘retired’ field for a particular tag ID. I don’t see how anybody could decide to use this without this basic information. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [August 29, 2025, 3:26pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/5 "2025-08-29T15:26:30Z")
I don't know all the details, but I think as part of 8.3 in general, I think they were making improvements across all historian providers to handle tag renaming, etc so that history tables aren't required to be manually modified for things like this anymore. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 29, 2025, 3:35pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/6 "2025-08-29T15:35:37Z")
I'm not quite sure where this messaging got lost, but the purpose of the new "core" historian is precisely to be a "black box" where you **don't** have to think about it. It's not "another RDBMS to manage", its "a turn key embedded historian solution", precisely for the people who _don't_ want to think about it. Among the reasons _not_ to think about it - just because it's questDB today doesn't mean it will be in the future. By choosing to let us control the level of abstraction, you're also choosing to allow us to take over the pain of migrating to some other historian provider if we ever choose to in the future, or make any other optimizations. The second you start intervening in the internal table structure yourself, all bets are off. ---
**Author:** ![wfiller](https://avatars.discourse-cdn.com/v4/letter/w/2bfe46/32.png) [@wfiller](https://forum.inductiveautomation.com/u/wfiller)\ **Post date:** [August 29, 2025, 3:58pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/7 "2025-08-29T15:58:15Z")
> [@paul-griffith](#): > > provider if we ever choose to in the future, or make any other optimizations. The second you star Yeah but we had a case where somebody was accidentally storing tags with all null values, for a long time because nobody noticed. It has storage implications. There was also a glitch because they had the settings to store on change, so the historian did not respect the deadband and was storing them as fast as possible, but that’s another subject. I had to delete millions of tags from each monthly file. ---
**Author:** ![Kyle.Chase](https://avatars.discourse-cdn.com/v4/letter/k/3bc359/32.png) [@Kyle.Chase](https://forum.inductiveautomation.com/u/Kyle.Chase)\ **Post date:** [August 29, 2025, 5:43pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/8 "2025-08-29T17:43:34Z")
QuestDB, the product, does not support deleting values. There is no way to purge stale tags. ---
**Author:** ![leonard.smit](https://avatars.discourse-cdn.com/v4/letter/l/cab0a1/32.png) [@leonard.smit](https://forum.inductiveautomation.com/u/leonard.smit)\ **Post date:** [October 2, 2025, 1:40pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/9 "2025-10-02T13:40:54Z")
Like the idea of having that level of abstraction, only question would be is there then a standard way to “query“ historical records outside of the platform?(without the use of the Web Dev module). ---
**Author:** ![wfiller](https://avatars.discourse-cdn.com/v4/letter/w/2bfe46/32.png) [@wfiller](https://forum.inductiveautomation.com/u/wfiller)\ **Post date:** [October 2, 2025, 1:52pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/10 "2025-10-02T13:52:58Z")
Same question as leonard.smit for me now. It seems like the most common answer is to install historian of your choice and use splitter which is unfortunate. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [October 2, 2025, 1:58pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/11 "2025-10-02T13:58:37Z")
> [@leonard.smit](#): > > a standard way to “query“ historical records outside of the platform? Yes, with the WebDev module. > [@leonard.smit](#): > > (without the use of the Web Dev module). No, use the WebDev module. (Or write your own 3rd party module with the SDK.) ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 2, 2025, 3:29pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/12 "2025-10-02T15:29:26Z")
I believe \[1\] that we're planning to add some automatic routes to the historian module to expose the data as a fairly standard HTTP service (so you wouldn't need Webdev unless you needed something more customizable). But: 1. I have no idea if that's actually still the plan (not my area of the product) 2. I have no idea _when_ that would happen if it is still happening. * * * 1. don't take this as a guarantee of anything ---
**Author:** ![leonard.smit](https://avatars.discourse-cdn.com/v4/letter/l/cab0a1/32.png) [@leonard.smit](https://forum.inductiveautomation.com/u/leonard.smit)\ **Post date:** [October 3, 2025, 8:18pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/13 "2025-10-03T20:18:05Z")
Thanks for the feedback, is there currently any SDK example to query the new historian module from the SDK? Any documentation for 8.3? ---
**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\ **Post date:** [November 7, 2025, 4:28pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/14 "2025-11-07T16:28:46Z")
> [@paul-griffith](#): > > I believe that we're planning to add some automatic routes to the historian module to expose the data as a fairly standard HTTP service (so you wouldn't need Webdev unless you needed something more customizable). Is this information from QuestDB regarding Ignition 8.3 what you are referring to? > [Ignition 8.3 | QuestDB](https://questdb.com/docs/third-party-tools/ignition/#direct-queries) > **Direct queries** > Ignition can be configured to expose QuestDB's Postgres wire server, allowing for read queries to be run directly against the underlying database. > > - `historian.questdb.pgwireServerEnabled` > - Corresponds to `pg.enabled` in QuestDB's `server.conf` > - Enables the PG Wire server on the default port (8812). > > - `historian.questdb.pgwireServerPort` > - Corresponds to the port half of `pg.net.bind.to` in QuestDB's `server.conf`. > - Changes the server port from the default (8812) to the specified integer. Also noted in Ignition manual: > [Gateway and Gateway Network Parameters | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.3/appendix/reference-pages/gateway-configuration-file-reference/gateway-and-gateway-network-parameters#core-historian) > **Core Historian** > The Core Historian is packaged with a PGWire Server to allow direct read-only access to the data. Use the following parameters to opt-in to this service and adjust the port as needed... ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [November 7, 2025, 4:44pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/15 "2025-11-07T16:44:19Z")
No, that's a different thing. What I was told was that we wanted to have an automatic HTTP endpoint (e.g. in the new Rest/OpenAPI) that would allow you to run history queries against whatever providers you have registered and would return data in a set format. That would be easier for external services to consume, since pretty much all of them can consume JSON-over-HTTP in some way or another. As of the current codebase (what will become 8.3.3) that hasn't been implemented. Like I hedged in my original post - I have no idea if that's still the plan or when it might happen if it is. ---
**Author:** ![diat150](https://avatars.discourse-cdn.com/v4/letter/d/a587f6/32.png) [@diat150](https://forum.inductiveautomation.com/u/diat150)\ **Post date:** [November 7, 2025, 8:38pm UTC](https://forum.inductiveautomation.com/t/questdb-official-documentation/110124/16 "2025-11-07T20:38:37Z")
> [@Kyle.Chase](#): > > QuestDB wow thats a bummer. sometimes devices fail and throw very large numbers which would make trending with automatic scaling useless. Is it possible for you guys to add a extra column that can be flagged to skip a row since we cant delete? Or is it possible to update a value for a particular row?