# Create DB Table Historian via scripting

**URL:** <https://forum.inductiveautomation.com/t/create-db-table-historian-via-scripting/111876>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [November 2, 2025, 5:24pm UTC](https://forum.inductiveautomation.com/t/create-db-table-historian-via-scripting/111876 "2025-11-02T17:24:48Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![drojas](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/drojas/32/3403_2.png) [@drojas](https://forum.inductiveautomation.com/u/drojas)\
**Post date:** [November 2, 2025, 5:24pm UTC](https://forum.inductiveautomation.com/t/create-db-table-historian-via-scripting/111876/1 "2025-11-02T17:24:49Z")

</div>

Anyone know if it is possible to script the creation of a DB Table Historian? When I script the creation of a database connection, the corresponding tag historian is created automagically, but there is no built-in system functions for managing the historians.

---

<div class="post-metadata">

**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 3, 2025, 4:23pm UTC](https://forum.inductiveautomation.com/t/create-db-table-historian-via-scripting/111876/2 "2025-11-03T16:23:47Z")

</div>

Nothing supported - you'll have to reach into complicated scripting territory to do so. Anything you do come up with will not work in 8.3, guaranteed - though the migration path should be very easy via the REST API or, if it's a late enough upgrade, the `system.config` namespace we're planning to add to 8.3.

---

<div class="post-metadata">

**Author:** ![drojas](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/drojas/32/3403_2.png) [@drojas](https://forum.inductiveautomation.com/u/drojas)\
**Post date:** [November 3, 2025, 4:54pm UTC](https://forum.inductiveautomation.com/t/create-db-table-historian-via-scripting/111876/3 "2025-11-03T16:54:00Z")

</div>

Ok. While I’m not afraid of the complicated scripting, I do plan on upgrading to 8.3 soon, so it might be worth the wait. If I understand this correctly, the `system.config` namespace would allow to pretty much CRUD any of the configuration settings we already do on the gateway? (i.e. remote tag providers, user sources, audit profiles, security services, gateway network approvals…etc.) These are some of the things that manually have to be created anytime I add a new remote/edge site.

---

<div class="post-metadata">

**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 3, 2025, 5:19pm UTC](https://forum.inductiveautomation.com/t/create-db-table-historian-via-scripting/111876/4 "2025-11-03T17:19:26Z")

</div>

That's the plan. Everything that you can do via CRUD in the REST API will be possible via `system.config` - some ergonomics will obviously be different but the final capability should be exactly equivalent.

Worth noting also that there may be better options for the "manually create all the things each time" story - e.g. the `external` resource collection in 8.3:

> [@Building Custom Ignition Gateway Docker Images](https://forum.inductiveautomation.com/t/building-custom-ignition-gateway-docker-images/111899/2):
>
> Don't mount into /data/, that's too broad. If you need to load 'gateway config', then mount the things you care about from /data/config/resources/core/ (on your development system) into the container at the /data/config/resources/external/ directory. The external directory is automatically scanned in on gateway startup and treated as an immutable set of resources that the gateway will not ever attempt to make changes to. Some more context: The project inheritance situation is different, but …
