# Ignition Edge - Buffer limitations **URL:** \ **Category:** Ignition\ **Created:** [August 2, 2025, 8:59am UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281 "2025-08-02T08:59:40Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Andre\_Hennecke](https://avatars.discourse-cdn.com/v4/letter/a/e95f7d/32.png) [@Andre\_Hennecke](https://forum.inductiveautomation.com/u/Andre_Hennecke)\ **Post date:** [August 2, 2025, 8:59am UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/1 "2025-08-02T08:59:40Z")
Hi, The current Ignition edge can buffer data for up to 35 days or 10Mio data points. I was wondering about the definition of a data point. I’m seeking clarification on the **definition of a "data point"**. Specifically, if we were to use Ignition Edge as a buffer during network interruptions, and we have **500 tags** **updating every second** , this would generate **500 data points per second**. Based on this rate, the 10 million data point buffer would be exhausted in approximately **5.5 hours**. Can you confirm whether this interpretation is correct, or if there are any optimization strategies extend the effective buffer time in this scenario? Thank you, André ---
**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 2, 2025, 2:23pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/2 "2025-08-02T14:23:35Z")
Your assessment is correct, in that the Edge historian can store up to 10M rows of data (in your case, one row per tag per second). If you're not careful (and are syncing data to a full gateway w/ a historian), this amount of data can result in \>100GB of disk space required each month. Spend time to set appropriate storage settings for each tag to minimize the data you're storing. Utilize an appropriate [Tag History Deadband Style](https://www.docs.inductiveautomation.com/docs/8.1/ignition-modules/tag-historian/configuring-tag-history#deadband-discrete-style-and-analog-compression), and store only _significant_ value changes. ---
**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 2, 2025, 3:34pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/3 "2025-08-02T15:34:15Z")
> [@Andre\_Hennecke](#): > > if there are any optimization strategies When you use "Analog" deadband style on your per-tag history settings, with a non-zero deadband, the Ignition historian will check that against the tag's **trend line** , not the most recent value, and will suppress extra stored points. The short term trend lines are recomputed on query to reconstruct with interpolation. (Do read the docs on how sample recording is delayed in this mode.) When you use "Discrete" deadband style, new values are checked against just the prior data point. When the actual data source behaves like a typical analog sensor, with a little noise (within the deadband), the analog deadband style is a big space saver. The **default** deadband style is "Auto", which mean "Analog" for floating point tags, and "Discrete" for all others. Further note: the 10 million row limit does **not** trigger pruning. Buffering simply stops. Pruning only happens at the 35-day boundary. You must make sure your application will not produce 10 million rows in any 35-day period, or you **will** lose data. If you cannot achieve this, you cannot use Ignition Edge. ---
**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 2, 2025, 4:35pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/4 "2025-08-02T16:35:28Z")
> [@pturmel](#): > > You must make sure your application will not produce 10 million rows in any 35-day period Or, utilize Edge Sync services to a full gateway, where all data will be forwarded based on sync period defined in the Edge gateway. ---
**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 2, 2025, 4:42pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/5 "2025-08-02T16:42:14Z")
> [@Chris\_Bingham](#): > > Or, utilize Edge Sync services I don't think Sync Services triggers any pruning on the Edge side, so I wouldn't expect this to help. You have experience otherwise? ---
**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 2, 2025, 5:21pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/6 "2025-08-02T17:21:55Z")
> [@pturmel](#): > > I don't think Sync Services triggers any pruning on the Edge side, Correct. But, sync services are agnostic of pruning. All historical data still in the Edge gateway (that has not already been received by Full gateway - confirmed by acknowledgement sent by Full gateway) is sent while comms are up (reasonable to expect \<30sec delay for all real time data from Edge if trending data from a full gateway). As long as sync settings (payload size & period) exceed data ingress, no data will be **lost** , despite not directly accessible by Edge after 10M rows or pruning passes. ---
**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 2, 2025, 5:30pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/7 "2025-08-02T17:30:20Z")
I'm referring to incoming data points being **dropped** up front because the row limit has been reached. Those data points will never be seen by Sync Services. Ergo, let me repeat: > [@pturmel](#): > > You must make sure your application will not produce 10 million rows in any 35-day period, or you **will** lose data. If you cannot achieve this, you cannot use Ignition Edge. I'd like to be **shown** to be wrong. ---
**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 2, 2025, 6:38pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/8 "2025-08-02T18:38:55Z")
Ahhh, I understand your comment now. Data is stored FIFO (the oldest data is dropped to store the newest). Here is a trend from a client who opted for high-res data from an Edge Panel site. Here is a screenshot trending 3 weeks of data **from Edge project** (which is pushed via EAM from full GW): ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/3/a377b765752209b88a48ae3bf94c9dccc40a283f.png) Note that not a single tag has direct access to history older than approximately 1 week at this site. And another with the same trend from the full gateway (running the same project, except all queries are executed against the SQL DB when viewed on Full GW): ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/7/8763f97c89ae5112d4b905959764970868d10d72.png) Using the PowerChart (and all its glory) w/ aggregation (500pt w/ MinMax) - disregard any small changes you might spot on the trends. I assure you that all points on Edge exist in remote DB. Here are two more, trending only last 10 hrs of data: Edge: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/7/87f8a1979fc4a48159d4dc6f031d6a28c057762f.png) Full: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/a/8a2d8cf63d0cc1f8bfc495029da0f08d35c27f94.png) ---
**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 2, 2025, 6:50pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/9 "2025-08-02T18:50:31Z")
Ah, good to see. Has the FIFO behavior changed? There were posts some weeks ago where it wasn't FIFO. ---
**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 2, 2025, 7:07pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/10 "2025-08-02T19:07:21Z")
Surprising. I'm unsure of other behaviors. LIFO would be a dealbreaker for me. I believe that site is still on 8.1.28 (deployed mid 2023). ---
**Author:** ![Andre\_Hennecke](https://avatars.discourse-cdn.com/v4/letter/a/e95f7d/32.png) [@Andre\_Hennecke](https://forum.inductiveautomation.com/u/Andre_Hennecke)\ **Post date:** [August 2, 2025, 8:34pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/11 "2025-08-02T20:34:30Z")
Thank you for your feedback. We can see a similar behaviour as described by Chris - 10 Mio rows are visualised on an edge project with a time frame of 6-7 hours, but you can see the full timeframe on a standard gateway without any data gaps. So there must be a FIFO for the visualisation on the edge. But does this also count for the sync service in case of a disconnect to a standard gateway? **The doc says:** > Sync is unique in that if the connection to the remote Ignition Gateway is severed, the Edge Gateway will use its 35 days of storage as a Store and Forward buffer, allowing you to store up to 35 days of data before data is lost. Once the connection is restored, the Edge Gateway will send data over based on the max batch size and data frequency until all previous data is sent. It does not mention any row limitations. ---
**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 2, 2025, 10:31pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/12 "2025-08-02T22:31:56Z")
This might help: > [@Ignition Edge Local Storage Limit: What Happens When 10 Million Data Points Are Reached?](https://forum.inductiveautomation.com/t/ignition-edge-local-storage-limit-what-happens-when-10-million-data-points-are-reached/104469/7): > > As currently implemented: No later than every 60 seconds, the edge historian runs a maintenance task that finds the oldest timestamp in the historian, and then deletes all data older than (not equal to) that timestamp. There is no logic I can see to evict new incoming data eagerly, so you absolutely could exceed the row "limit" for some period of time until records are evicted. The tags.history.InternalHistorian.Engine logger on debug or trace would be informative to follow, OP. Note that Edge Sync Services are drawing from the Edge historian, so the row limit does apply to it. ---
**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 3, 2025, 12:52am UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/13 "2025-08-03T00:52:37Z")
> [@Andre\_Hennecke](#): > > does this also count for the sync service in case of a disconnect Yes. As @pturmel mentioned, Edge sync draws from the Edge historian, starting with oldest record still in the DB that has not already been sync'd. In your case (10M / 7hrs), if your connection to Full goes down for 8hrs (say, starting at noon), expect to **lose** 1hr of data (from noon-1p), as all data older than 1p will be evicted from Edge by the time it is able to S&F to Full. ---
**Author:** ![Andre\_Hennecke](https://avatars.discourse-cdn.com/v4/letter/a/e95f7d/32.png) [@Andre\_Hennecke](https://forum.inductiveautomation.com/u/Andre_Hennecke)\ **Post date:** [August 4, 2025, 7:58am UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/14 "2025-08-04T07:58:00Z")
Thank you both for the feedback and clarification. I do hope Inductive considers increasing the 10 million row limit in the future, as it doesn’t always align with today’s data velocity and growing needs. ---
**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 4, 2025, 11:48am UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/15 "2025-08-04T11:48:19Z")
> [@Andre\_Hennecke](#): > > as it doesn’t always align It aligns perfectly with IA's desire to offer a affordable, but limited, alternative to full-priced Ignition. If you need more than what Edge offers, buy Standard. It also aligns perfectly with IA's support model. More functionality =\> more support calls =\> more support cost that needs to be born by the license cost. I wouldn't hold your breath waiting for this to change. ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [August 4, 2025, 12:01pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/16 "2025-08-04T12:01:09Z")
> [@pturmel](#): > > I wouldn't hold your breath ... ⚠ Metaphor breakdown warning! ---
**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 4, 2025, 12:12pm UTC](https://forum.inductiveautomation.com/t/ignition-edge-buffer-limitations/109281/17 "2025-08-04T12:12:06Z")
> [@Transistor](#): > > Metaphor breakdown You've never had a family member threaten to hold their breath until they get their way?