# Power Chart Annotations With Remote History Provider

**URL:** <https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780>\
**Category:** Ignition\
**Tags:** ignition81, perspective\
**Created:** [August 13, 2026, 1:37pm UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780 "2026-08-13T13:37:51Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![James.Sletten](https://avatars.discourse-cdn.com/v4/letter/j/7ea924/32.png) [@James.Sletten](https://forum.inductiveautomation.com/u/James.Sletten)\
**Post date:** [August 13, 2026, 1:37pm UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/1 "2026-08-13T13:37:51Z")

</div>

Hello,

I think I already know the answer to this, but I wanted to see if anyone has found a workaround.

I have a distributed Ignition application with one backend gateway and one frontend gateway. The backend handles all I/O, database operations, and tag history. The frontend is only responsible for rendering applications.

When using the Perspective Power Chart, I would like to store annotations in the tag history database. My current architecture uses remote history providers, allowing the frontend gateway to retrieve historical data from the backend gateway. The issue is that a remote history provider connection is read-only, which prevents annotations from being written to the database.

The only workaround I can think of is creating a database connection on the frontend gateway that points to the same historical database used by the backend. This would allow annotations to be written successfully. However, I would prefer to keep the frontend read-only and have the backend remain responsible for all database writes.

Thoughts and or ideas?

---

<div class="post-metadata">

**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 13, 2026, 1:54pm UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/2 "2026-08-13T13:54:53Z")

</div>

~~You are trying to coerce Ignition's historians to store annotations for tags, which they are not designed to do. But they **can** store string tags on change--a possible approach, but you will be limited to single notes at a given millisecond timestamp.~~

The canonical approach would be to use a non-historian DB table to store events in your desired format. With DB connections on both front and back ends. (Where you do the writes is application dependent.)

---

<div class="post-metadata">

**Author:** ![James.Sletten](https://avatars.discourse-cdn.com/v4/letter/j/7ea924/32.png) [@James.Sletten](https://forum.inductiveautomation.com/u/James.Sletten)\
**Post date:** [August 13, 2026, 2:21pm UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/3 "2026-08-13T14:21:42Z")

</div>

@pturmel Thanks for the response.

When you say that Ignition historians are not designed to store annotations, could you clarify what you mean? It seems that there are mechanisms in place within the historian to support annotations, see links below.

I've tested and used this successfully on a single Ignition gateway. However, in a distributed architecture, the read-only nature of remote history providers and my architecture creates the unique challenge described above.

**See annotate section at the link below:**

> **[Perspective - Power Chart | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/appendix/components/perspective-components/perspective-chart-palette/perspective-power-chart)**
>
> The Power Chart collects and displays data based on the pens that have been configured on the chart.

**See sqlth\_annotations section at the link below:**

> **[sqlth\_annotations​ - Ignition Database Table Reference | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/appendix/reference-pages/ignition-database-table-reference#sqlth_annotations)**
>
> Ignition has a lot of systems built-in that will query the database automatically without requiring you to build a query. These systems automatically create the necessary tables in the database, insert the relevant data, and even query it back out...

---

<div class="post-metadata">

**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 13, 2026, 2:23pm UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/4 "2026-08-13T14:23:49Z")

</div>

Hmm. I stand corrected. I've never used that. (Probably because performance has always kept me from using the Power Chart.)

---

<div class="post-metadata">

**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\
**Post date:** [August 14, 2026, 11:34pm UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/5 "2026-08-14T23:34:09Z")

</div>

> [@pturmel](#):
>
> performance has always kept me from using the Power Chart

There are many reasons **not** to use PowerChart, but I’ve not seen performance as one of them (at least, not anything _recent_). Can you elaborate?

---

<div class="post-metadata">

**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 15, 2026, 2:54pm UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/6 "2026-08-15T14:54:35Z")

</div>

Last focused attempt to use the power chart was about a year ago, to add to my tag report exchange resource. Abysmal performance, effort abandoned.

---

<div class="post-metadata">

**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\
**Post date:** [August 16, 2026, 4:24am UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/7 "2026-08-16T04:24:40Z")

</div>

Am I to assume your comparison was with a 3rd party library? If so, I agree, a couple I demoed were almost an unfair comparison.  
If otherwise, your results in comparing the core trend components differ from my own...

---

<div class="post-metadata">

**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\
**Post date:** [August 16, 2026, 4:33am UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/8 "2026-08-16T04:33:04Z")

</div>

> [@James.Sletten](#):
>
> However, in a distributed architecture, the read-only nature of remote history providers

I'm fairly certain that Read Only is just the default action, and that you are able to permit write access via updating [Remote History Provider - Storage](https://www.docs.inductiveautomation.com/docs/8.1/ignition-modules/tag-historian/tag-history-providers#storage) settings, then verifying that service aecurity permits write access.

---

<div class="post-metadata">

**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 16, 2026, 1:45pm UTC](https://forum.inductiveautomation.com/t/power-chart-annotations-with-remote-history-provider/116780/9 "2026-08-16T13:45:47Z")

</div>

> [@Chris\_Bingham](#):
>
> comparison was with a 3rd party library?

Yes, but also against the Time Series chart. The TS chart was modestly faster at the time, which is why it is still in the exchange project.
