# Side bucket catalog for time series updates and deletes > Source-anchored research for Side bucket catalog for time series updates and deletes. Run status: COMPLETED. Parent: [Bucket catalog memory and closure reasons](https://llms-explorer.com/tree/bucket-catalog-memory-and-closure-reasons/) · 3 facets · 9 facts · page: https://llms-explorer.com/tree/side-bucket-catalog-for-time-series-updates-and-deletes/ ## How it works - When the stage is destroyed and has newly inserted bucket IDs, it finishes their direct-write tracking in the global catalog and merges the side catalog collection execution statistics into that catalog. Consequently, those statistics are not necessarily a separate reporting namespace. (low confidence) (verified as of 2026-10-24) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/exec/classic/timeseries_modify.cpp) ## Problems, failure modes and limitations - For multi updates, the implementation guide describes spooling scanned bucket record IDs and inserting updated measurements into new buckets to avoid the Halloween problem; the spool can spill when its memory limit is reached. (low confidence) (verified as of 2026-10-24) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/timeseries/README.md) ## Facts and statements - In the inspected master implementation, TimeseriesModifyStage allocates a side BucketCatalog only for updates, with one stripe and getTimeseriesSideBucketCatalogMemoryUsageThresholdBytes as its threshold callback. (medium confidence) (verified as of 2026-10-24) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/exec/classic/timeseries_modify.cpp) - Measurement updates remove old values and insert changed measurements into new buckets; unchanged measurements remain in the original bucket, which is deleted if none remain. (high confidence) (verified as of 2026-10-24) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/timeseries/README.md) - timeseriesSideBucketCatalogMemoryUsageThreshold controls idle-bucket expiry in the side catalog. The inspected MongoDB parameter definition and ApsaraDB 8.0 table specify a default of 104857600 bytes; the MongoDB definition permits startup and runtime changes. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/timeseries/timeseries.idl) - Measurement deletes repack surviving measurements into the original bucket, or delete that bucket if none survive. A predicate covering a whole bucket can bypass unpacking. The delete helper receives no side catalog. (high confidence) (verified as of 2026-10-24) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/timeseries/README.md) - ApsaraDB’s kernel-parameter release notes list the side-catalog memory threshold for MongoDB 8.0 in the July 2025 additions. This dates the managed-service exposure, not the upstream feature’s introduction. (low confidence) (verified as of 2026-06-22) — [source](https://www.alibabacloud.com/help/en/mongodb/product-overview/engine-release-notes) - timeseriesSideBucketCatalogMemoryUsageThreshold defaults to 104857600 bytes (100 MiB). Upstream IDL and Alibaba MongoDB 8.0 documentation describe it as the memory threshold above which idle side-catalog buckets expire; they do not describe a strict total-memory ceiling. (medium confidence) (verified as of 2026-10-24) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/timeseries/timeseries.idl) - Upstream IDL allows the side-catalog threshold to be set at startup or runtime. Alibaba lists its managed MongoDB 8.0 parameter with a 52428800–209715200-byte range and no restart requirement. That service range must not be assumed to be an upstream validator. (medium confidence) (verified as of 2026-10-24) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/timeseries/timeseries.idl)