Why Is Ignition QuestDB Historian Missing from Query Browser?

The status page shows the Internal Historian (QuestDB) storing tag data, yet the provider never appears in the Designer's Database Query Browser dropdown. This is normal. The Query Browser lists only gateway database connections, and the internal QuestDB historian does not run through a database connection. To browse it with SQL, enable QuestDB's Postgres wire interface (PGwire) in ignition.conf, restart the gateway, and create a separate read-only Postgres connection that points at it.

Why does the historian report healthy while the Query Browser list stays empty?

Ignition 8.3 embeds QuestDB as a storage engine inside the gateway process. Tag history writes go straight to that embedded engine through the historian subsystem. No JDBC connection is involved. The Database Query Browser only enumerates entries under the gateway's Database Connections, so a historian that never created one has nothing to list.

Two different layers are involved here:

• Historian provider: what tags bind to, what the status page reports, and what queryTagHistory and the system.historian.* functions read from.
• Database connection: a JDBC link that the Query Browser, named queries, and system.db.* use.

A healthy provider with no Query Browser entry means the provider layer works and the connection layer was never built. That is a missing binding, not a data fault.

Inductive Automation ships QuestDB Embedded, not QuestDB Enterprise. Enterprise features such as high availability, role-based security, and tiered storage are not present. Synchronizing the internal historian through Ignition redundancy is under development and was not available at the time of writing.

What does each screen actually tell you?

Read the screens in this order to separate a storage problem from a connection problem.

Which access path fits: scripting, a local Postgres connection, or a proxy?

Each path answers a different need.

Recommendation:

• For application reads such as charts, reports, and scripts, use the built-in historian functions. That is the intended path, and it survives future changes to the storage engine.
• To inspect data in the Query Browser, validate stored values, or explore the database, build the local Postgres connection.
• Use a proxy only when an external analytics host needs SQL access, and load-test it first.

How do I enable PGwire and build the Postgres connection?

1. Stop the gateway, or plan a restart window. The ignition.conf change only takes effect after a gateway restart.
2. Open ignition.conf and add the parameter that enables PGwire for the internal historian. Take the exact parameter name and syntax from the Gateway and Gateway Network Parameters page of the Ignition User Manual. Do not guess it. On Docker, pass the same gateway parameter through your container's gateway-argument mechanism so it persists across container recreation.
3. Restart the gateway.
4. In the gateway web interface, open the JDBC driver list at /app/connections/databases/settings/drivers-jdbc and confirm a PostgreSQL driver is present. If it is missing, go to the Docker section below before continuing.
5. Create a new database connection with the PostgreSQL driver and these values:

   Connection URL: jdbc:postgresql://localhost:8812/qdb
   Username:       user
   Password:       ignition

6. Save the connection and wait for its status to show valid.
7. Open the Designer, then the Database Query Browser, and select the new connection from the dropdown.

What if PostgreSQL is missing from the driver list on a Docker install?

A fresh Ignition 8.3 install includes a Postgres JDBC module by default. When the driver dropdown has no PostgreSQL entry, the module is either disabled or was never loaded.

On Docker, the usual cause is a compose file carried over from an earlier release. The module list changed significantly in 8.3. An old compose file with an explicit enabled-modules flag leaves the Postgres JDBC module out, and the gateway silently skips it.

1. Open the compose file and find the enabled-modules setting.
2. Compare its module list against the modules shipped with your 8.3 image. Add the Postgres JDBC module, or remove the restriction if you do not need one.
3. Recreate the container.
4. Recheck /app/connections/databases/settings/drivers-jdbc for the PostgreSQL driver.
5. Confirm the PGwire gateway parameter is still applied in the new container.

Do not upload a third-party PostgreSQL JDBC jar to work around this. The bundled module is the supported driver, and the fault is the module list, not a missing driver file.

What are the limits on remote access, credentials, and redundancy?

• Loopback only. The PGwire listener binds to the loopback interface. Exposing port 8812 externally is not a supported option. Only processes on the gateway host, including the gateway's own JDBC connection, can reach it directly.
• Proxy workaround. A proxy on the gateway host that forwards to localhost:8812 has been used to read the historian from a different server. Treat it as unsupported. Benchmark heavy analytical queries against historian write load before relying on it, because both share the same embedded engine and host.
• Fixed credentials. The user/ignition login is not configurable. The loopback binding and read-only mode are the only protection at the database layer. If a site requires read access to be restricted as well, control access at the Ignition layer: limit who can open the Designer and who can use the database connection in project resources. Do not rely on the database login.
• Read-only. Writing arbitrary data into the internal historian is not a planned feature. Keep manual SQL writes, lookup tables, and custom data in a separate database.
• Scope. The internal historian stores tag history only. Alarm journal and audit log data still require a SQL database connection. Migrating them to the internal historian is on the long-term roadmap, with no release committed.
• High availability. QuestDB Embedded provides no replication or HA. Native synchronization through Ignition redundancy is in development. Until it ships, a history splitter feeding both a local internal historian and a remote historian on the backup gateway over the Gateway Network is the candidate design. Validate gap behavior during failover before trusting it.
• Upgrades from 8.1. Existing SQL-based tag history providers can stay in place. Moving tags to the internal historian means pointing them at the new provider, and scripts may need the system.historian.* functions. Check the Historian Functions section of the manual for the calls that apply to your provider.

How do I confirm the Query Browser is reading live historian data?

1. In the gateway, confirm the new Postgres connection shows a valid status. A faulted connection means PGwire is off, the gateway was not restarted, or the URL/port is wrong.
2. In the Designer's Database Query Browser, select the connection and run SHOW TABLES; to list the historian's tables.
3. Pick the table that holds tag values and run a bounded query, for example SELECT * FROM <table> LIMIT 20;, to inspect column layout and recent rows.
4. Force a value change on a tag assigned to the internal historian, wait one storage cycle, and re-run the query. The new sample should appear with a current timestamp.
5. Cross-check the same tag and time range with queryTagHistory or a trend. Scripting and SQL should return matching values.
6. Attempt a harmless write such as an INSERT into a scratch name and confirm it is rejected. A rejection proves you are on the read-only interface and cannot corrupt stored history.

Frequently asked questions