# Best practice for handling large-scale OPC UA Structured DataTypes / ExtensionObjects

**URL:** <https://forum.inductiveautomation.com/t/best-practice-for-handling-large-scale-opc-ua-structured-datatypes-extensionobjects/114706>\
**Category:** Ignition\
**Tags:** ignition80, ignition83\
**Created:** [March 26, 2026, 9:01pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-handling-large-scale-opc-ua-structured-datatypes-extensionobjects/114706 "2026-03-26T21:01:37Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Adarsh\_K](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Adarsh\_K](https://forum.inductiveautomation.com/u/Adarsh_K)\
**Post date:** [March 26, 2026, 9:01pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-handling-large-scale-opc-ua-structured-datatypes-extensionobjects/114706/1 "2026-03-26T21:01:37Z")

</div>

Hi all,

We have a shopfloor where most machine data is exposed via **OPC UA Structured DataTypes / ExtensionObjects** instead of simple atomic tags. This is based on a standard machine information model, so values and metadata like unit, limits, ID, timestamp, status, etc. come together as one structured object.

The overall scale is large around **100k shopfloor tags/signals** follow this pattern.

I understand Ignition can connect and read these, but practically they seem to come in as **Document/JSON** rather than fully expanded member tags.

I wanted to ask what is the **best and most scalable way** to handle this in Ignition.

- Should we keep the structured object as the source and only extract required members into derived tags?

- Should we flatten things upstream before Ignition?

- Is there a recommended UDT-based abstraction approach in Ignition for this?

- What are the real performance concerns at this scale for subscriptions, tag count, memory, historian, alarming, and UI bindings?

- Any known limitations with custom structured datatypes / ExtensionObjects / datatype definitions in current Ignition versions?

Mainly looking for **best practice from people who have implemented this in production** , especially at large scale.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [March 26, 2026, 9:31pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-handling-large-scale-opc-ua-structured-datatypes-extensionobjects/114706/2 "2026-03-26T21:31:27Z")

</div>

Some key information that will inform whatever decision you make is:

- does the server also expose the structure members as their own variable nodes in the address space?
- is this a "real" server that could handle the load of 100k monitored items, or an embedded server on a PLC where it's crucial you only create monitored items for the structure value nodes?

---

<div class="post-metadata">

**Author:** ![Adarsh\_K](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@Adarsh\_K](https://forum.inductiveautomation.com/u/Adarsh_K)\
**Post date:** [March 27, 2026, 5:03pm UTC](https://forum.inductiveautomation.com/t/best-practice-for-handling-large-scale-opc-ua-structured-datatypes-extensionobjects/114706/3 "2026-03-27T17:03:13Z")

</div>

> [@Kevin.Herron](#):
>
> does the server also expose the structure members as their own variable nodes in the address space?

Hi Kevin ,

does the server also expose the structure members as their own variable nodes in the address space? - **Yes this tags will be exposed to MES via Ignition OPC UA server**  
is this a "real" server that could handle the load of 100k monitored items, or an embedded server on a PLC where it's crucial you only create monitored items for the structure value nodes? - **Not one single server but combination of 4 gateways**  **with EAM**

Thanks