topic Re: Ballooning Feature Layer Size in ArcGIS Online Questions

Ballooning Feature Layer Size

mpboyle — Fri, 05 Dec 2025 19:33:47 GMT

We have a feature layer that over the past couple days has ballooned in size with no reasonable explanation I can find.

This feature layer contains approximately 11k line features and less than 10 fields. Every 10 minutes the feature layer has all rows deleted and replaced using a feature set and the Python API.

This morning I manually overwrote the feature layer, and the item size was around 5MB. A few hours later, the item has ballooned in size to 250MB!?!

The feature layer does NOT have editing enabled, no associated views, no extra indexes, does NOT have optimize layer drawing enabled, and no attachments.

Is there any reasonable explanation for why this feature layer continues to balloon in size?

Re: Ballooning Feature Layer Size

D_Atkins — Fri, 05 Dec 2025 20:26:06 GMT

Throwing things at the wall, here:

Problem: Hosted Feature Service Size Increases Continuously

Re: Ballooning Feature Layer Size

mpboyle — Fri, 05 Dec 2025 20:39:33 GMT

Editing is not enabled, sync not enabled.

Re: Ballooning Feature Layer Size

MobiusSnake — Sat, 06 Dec 2025 05:43:50 GMT

I don't have an explanation, but maybe something to try. If you're currently using deleteFeatures() or editFeatures() in the API, see whether it still happens if you switch to FeatureLayerManager.truncate().

Re: Ballooning Feature Layer Size

MichaelVolz — Sun, 07 Dec 2025 17:18:18 GMT

Do you see any noticeable increase in AGOL credit use due to the increased hfl size?

Do you have other hfls with the same workflow that exhibit this behavior?

Re: Ballooning Feature Layer Size

mpboyle — Mon, 08 Dec 2025 16:10:56 GMT

I was curious about the same, so I created a script that pulls the size of some of our hosted feature layers. It includes a mix of those that we update via publishing a file geodatabase, and those that we update via deleting/adding features.

The feature layers that are published from a file geodatabase do NOT show increased item size. Those that are updated using delete/add features DO show increased item size even though the number of features is NOT increasing proportional to their shown size.

We ARE seeing this ballooning reflected in our credit usage.

Below are some charts displaying what we're seeing.

Example 1: This feature layer is updated every 30 minutes using delete/add features. On Friday afternoon the size of the feature layer was about 17-18MB. It is now showing about 45MB.

The number of features and populated fields in this feature layer remains relatively consistent.

Example 2: This feature layer is updated every 2 minutes using delete/add features. On Friday afternoon the size of the feature layer was about 2MB. It is now showing about 7MB.

The number of features in this feature layer does oscillate but is likely never above 40 features.

Example 3: This feature layer is updated once a day by publishing a file geodatabase. The size remains consistent.

Example 4: Below is snapshot of our available credits near the end of the day for the past few days (the DateValue field is set to noon UTC for our time zone). The "CreditsUsed" field is calculated from the previous day's value.

We first noticed one of our hosted feature layers ballooning in size on Friday, 12/5/2025. Once we noticed it, I changed this feature layer to be updated via publishing a file geodatabase.

You can see the noticeable bump in credit usage on Thursday, 12/4, and Friday, 12/5. Once the feature layer in question was changed to be updated via a file geodatabase, the credit usage remained steady on Saturday, 12/6 and Sunday, 12/7.

I would really like an explanation from someone at Esri as to why this is happening (apologies to the Esri staff I tagged, you all showed up as top collaborators).
@EmilyGeo @RussRoberts @George_Thompson

Re: Ballooning Feature Layer Size

George_Thompson — Mon, 08 Dec 2025 16:52:46 GMT

This is something that I would work with technical support on. I do not have any visibility behind the scenes and how the size is calculated or why it is increasing in your case.

Re: Ballooning Feature Layer Size

troyf_PTC — Mon, 08 Dec 2025 20:58:34 GMT

I have struggled with this ever since we started using ArcGIS Online back in 2018, but recently it seems like it has gotten worse over the past couple of years and sometimes fixes that worked before don't always work now.

(I already have a case open under another account for this issue with a specific feature service that is sitting at over 1GB of feature data and 59GB of attachments that refuses to shrink, and attempts to overwrite the feature service through ArcGIS Pro were unsuccessful, but enough about that).

I always noticed this with layers that were updated via FME Desktop or FME Server (which just use the REST APIs behind the scenes). Usually I can eventually trim it down by removing all editing tracking, disabling offline access, and within the REST Admin page removing all replicas, removing and trimming the change tracking, and compressing the feature service.

But like you said, you don't have offline or editing enabled. I suspect that they are building in and using a lot more change-tracking tables behind the scenes, even when the "Keep Track of changes to the data" is supposedly disabled within the Feature Service settings page... but I don't have much proof to support that theory...

Re: Ballooning Feature Layer Size

mpboyle — Tue, 09 Dec 2025 15:33:58 GMT

I was aware of the truncate method within the FeatureLayerManager and was hesitant to use it due to its restrictions, outlined here. However, I did change one of our scripts to use this rather than FeatureLayer.delete_features to see if it provided any change. And...it seems to have done the job!

I made the change to this script around 11:30AM, and by about 1PM the feature layer showed a substantial reduction in item size, see first graph below. The item size looks to have remained consistent since making the change to use FeatureLayerManager.truncate.

In the second graph below is one of our hosted feature layers that's still using FeatureLayer.delete_features. You can see this feature layer continues to grow in item size.

I won't speculate on what's being done behind the scenes by Esri, but it does seem that using the truncate method flushes/resets/removes something that the delete_features method is not.

Example 1: Hosted feature layer changed to using FeatureLayerManager.truncate at around 11:30AM on 12/8/2025. Substantial drop in item size noticed around 1PM and item size looks to remain consistent.

Example 2: Hosted feature layer still using FeatureLayer.delete_features and the item size continues to grow.

Re: Ballooning Feature Layer Size

MichaelVolz — Tue, 09 Dec 2025 16:06:01 GMT

From my experience with on-prem data in file gdbs and enterprise gdbs, Truncate is much better than Delete_Features as it seems to keep data compressed. I tried to update a fairly large line feature class using Delete_Features every 5 minutes and after a few days the feature class slowed to a crawl. Once I applied the Truncate method, the performance stayed consistent as well as the file size.

Re: Ballooning Feature Layer Size

mpboyle — Tue, 09 Dec 2025 16:26:00 GMT

Yea, when we're doing anything with internal datasets (ex: file gdb or enterprise gdb), we use truncate over deleting features. Makes sense to use it with feature layers too.

Re: Ballooning Feature Layer Size

MichaelVolz — Tue, 09 Dec 2025 16:32:19 GMT

So based on this behavior, when would anyone not want to use Truncate instead of Delete_Features?

Re: Ballooning Feature Layer Size

mpboyle — Tue, 09 Dec 2025 17:01:57 GMT

I can see scenarios where you may just want to delete certain features using a where clause. For example, we have a hosted feature layer that stores point-in-time data and has data written to it every 5 minutes. Once the data is written, it's not going to change, so there's not really a point in deleting all rows and replacing them. However, at some point we do want to trim the data within the feature layer, so we use delete_features to delete those feature older than a certain date. The graph below shows the item size for thisparticular feature layer. It's still growing over time, but at a much slower rate...possibly (likely?) because we aren't removing ALL features when it's updated, but rather deleting features once a day based on the date value.

If you're going to be replacing ALL features within a hosted feature layer, I think this makes the case to use truncate over delete_features.

Re: Ballooning Feature Layer Size

troyf_PTC — Tue, 09 Dec 2025 17:09:11 GMT

I know in my case (rural utility telecom), we started out truncating everything every night. But it had an impact on offline workflows and speed/efficiency for offline map syncing for our users, since it essentially deleted and re-populated the entire layers with the new GlobalIDs. And some things we just need creation and editor tracking and things like that, which get reset when the feature is re-created. And God forbid that a user made offline edits and didn't sync it before EoD. So for me it's always a balancing act between maintenance cost (ie: credit usage and performance and time spent on data administration) vs the stakeholder user experience, especially the mobile workers (utility locators, construction crews, field technicians) which tend to get frustrated easily.

Re: Ballooning Feature Layer Size

mpboyle — Tue, 09 Dec 2025 17:31:08 GMT

There are some limitations to the FeatureLayerManager.truncate method, which are shown below (REST docs found here), one of them being sync enabled feature layers.