# Adding TimescaleDB to Postgres

**URL:** <https://forum.inductiveautomation.com/t/adding-timescaledb-to-postgres/112750>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [December 10, 2025, 10:46pm UTC](https://forum.inductiveautomation.com/t/adding-timescaledb-to-postgres/112750 "2025-12-10T22:46:08Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Shea\_Molthen](https://avatars.discourse-cdn.com/v4/letter/s/c37758/32.png) [@Shea\_Molthen](https://forum.inductiveautomation.com/u/Shea_Molthen)\
**Post date:** [December 10, 2025, 10:46pm UTC](https://forum.inductiveautomation.com/t/adding-timescaledb-to-postgres/112750/1 "2025-12-10T22:46:08Z")

</div>

I’ve got a current PostgresDB system with a few partitions so far and I’m interested to converting to TimescaleDB.

I found [this guide](https://wiki.icstexas.com/books/ignition/page/using-postgresql-and-timescaledb-with-ignition) (thanks @michael.flagler - for sharing!). I’ve also seen some methods of migrating the old data to the new TimescaleDB table; I was wondering if this would even be required if I’m alright with the old partitions being slow/ in standard tables?

My thought would be to disable pruning in Ignition and convert the sqlth\_1\_data table to a hypertable. Ideally, queries on the new data would fully utilize TimescaleDB, and queries that access the old data would still work.

---

<div class="post-metadata">

**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:** [December 11, 2025, 12:12pm UTC](https://forum.inductiveautomation.com/t/adding-timescaledb-to-postgres/112750/2 "2025-12-11T12:12:45Z")

</div>

I think you're on the right track. You could possibly even use the guide to convert all the old tables to hyper tables if you wanted. In theory it should work. Make sure to disable both pruning and partitioning.

At this point you'll have to drop the old tables yourself whenever you don't need them.

---

<div class="post-metadata">

**Author:** ![Shea\_Molthen](https://avatars.discourse-cdn.com/v4/letter/s/c37758/32.png) [@Shea\_Molthen](https://forum.inductiveautomation.com/u/Shea_Molthen)\
**Post date:** [December 16, 2025, 2:23pm UTC](https://forum.inductiveautomation.com/t/adding-timescaledb-to-postgres/112750/3 "2025-12-16T14:23:50Z")

</div>

> [@michael.flagler](#):
>
> you

Thanks for the response. So even with multiple tables, I could still convert them to hypertables and Ignition would just query them separately? And then the future partitions will be all handled by Timescale?

Further, are there any other issues / things I should think about? I found this: [Problematic Historian Query with TimescaleDB - #8 by pascal.fragnoud](https://forum.inductiveautomation.com/t/problematic-historian-query-with-timescaledb/68760/8) and was wondering if Timescale still has this issue?

Thanks again!

---

<div class="post-metadata">

**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:** [December 16, 2025, 2:41pm UTC](https://forum.inductiveautomation.com/t/adding-timescaledb-to-postgres/112750/4 "2025-12-16T14:41:32Z")

</div>

I haven't had any issues on our projects, but we also don't have a really long runtime on anything yet. I do have compression enabled so it saves a ton of space on the servers and trends have been very fast.