Delete and re-insert safety on time series
Parent: Bucket fragmentation remediation (re-insert/merge) · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-3a39b842dcf7
↓ Facts as markdownall context files
Source-anchored research for Delete and re-insert safety on time series. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- For measurement-level time-series deletes whose predicate does not apply to the bucket document as a whole, MongoDB unpacks candidate buckets and checks each measurement. It repacks unaffected measurements into the original bucket with the same `_id`, and deletes a bucket only when every measurement matches. If the predicate applies to the whole bucket document, MongoDB skips unpacking and deletes the bucket directly. A partial measurement delete therefore does not itself rebucket surviving measurements. (high confidence) (verified as of 2026-10-20) [source]
- SERVER-99527 scopes a delete/reinsert defect to MongoDB 7.0.0-7.0.15 and 8.0.0-8.0.3. It requires a delete filter that omits metaField, the specified {metaField: 1, timeField: 1} index when a metaField exists or {timeField: 1} when it does not, and a subsequent measurement timestamp within the issue's listed window: 2 hours for seconds granularity, 2 days for minutes, 2 months for hours, or 2*bucketMaxSpanSeconds for custom bucketing. Under these conditions, inserted measurements may be prematurely deleted by TTL or omitted from time-filtered query results. The issue lists fixes in 7.0.16, 8.0.4, and 8.1.0-rc0. (high confidence) (verified as of 2026-10-14) [source]
- A 2023 DBA Stack Exchange question reports that indexed queries on a replacement time-series database took upwards of two minutes or returned no result after the user dropped an older database and created a new one. The question gives no confirmed cause and does not connect the slowdown to delete/reinsert or SERVER-99527. (low confidence) [source]
Problems, failure modes and limitations
- One community user reports that deleting and re-inserting 20,539 measurements left the logical count at 20,539 while bucket count fell from 3,120 to 370. The report does not prove value-by-value equality or a repeatable performance gain. A separate DBA Stack Exchange question describes slow queries after the user dropped an older time-series database and created a replacement; it does not report the same delete-and-reinsert procedure. (low confidence) [source]
- Two community users report slow deletes for small match sets or short time windows, including reports over one second and over ten seconds. These are workload-specific anecdotes and do not isolate bucket rewriting as the cause or benchmark a full reinsert remediation. (low confidence) [source]
- Version context matters: a 2021 Umea University thesis describes MongoDB 5.0 time-series collections as supporting inserts and reads but not manual updates or deletes, while the current MongoDB server README documents arbitrary updates and deletes. The historical 5.0 limitation should not be generalized to newer releases. (medium confidence) (verified as of 2026-10-20) [source]
Facts and statements
- MongoDB groups measurements by matching metaField values and bounded time spans, and buckets also have count and size limits. Re-inserting the same logical series can therefore still produce multiple bucket documents; the bucket rules do not guarantee one bucket per series or month. (medium confidence) (verified as of 2026-10-19) [source]
- MongoDB makes multi-document writes atomic per document, not as a whole, and other operations may interleave. A delete command followed by later inserts is not one all-or-nothing operation, so an interruption can leave a series partly removed or restored. (medium confidence) [source]
- MongoDB does not create a unique `_id` index on time-series collections, so copied `_id` values alone do not make a delete-and-reinsert retry idempotent. Validate expected measurements with an application-level key or content check after reinsertion. (medium confidence) (verified as of 2026-10-19) [source]
- A 2023 community answer says MongoDB 6.0.6 did not support deletes selected by a non-metaField timestamp filter, while the current server README describes arbitrary time-series deletes. Check the target server release before applying older delete limitations or current behavior. (medium confidence) (verified as of 2026-10-20) [source]
- A separate Jira report says non-metaField deletes on time-series collections sharded by timeField could lose bucket data on versions 7.0.0–7.0.15 and 8.0.0–8.0.3; it lists 7.0.16 and 8.0.4 as fixes. (low confidence) (verified as of 2026-09-04) [source]
- For measurement-level deletes whose predicate does not apply to the whole bucket document, MongoDB unpacks candidate buckets, checks each measurement against the delete predicate, and writes surviving measurements back under the original bucket `_id`. A predicate that applies to the whole bucket can skip unpacking and delete the bucket directly. SERVER-99527 explains that a partial delete can recalculate `control.min` while leaving the timestamp embedded in `_id` unchanged, which can affect subsequent query-based bucket reopening. (high confidence) [source]
Children
- No children recorded.