Scaling with a Sliding Time Window

Scaling with a Sliding Time Window

Use when only recent data needs fast search -- social media posts, news articles, support tickets, logs, job listings. Old data either becomes irrelevant or can tolerate slower access.

Three strategies: shard rotation (recommended), collection rotation (when per-period config differs), and filter-and-delete (simplest, for continuous cleanup).

Shard Rotation (Recommended)

Use when: data has natural time boundaries (daily, weekly, monthly). Preferred because queries span all time periods in one request without application-level fan-out. User-defined sharding

Create one shard key per time period, write to the current one, and delete the oldest shard key once it leaves the retention window. The Time-Based Sharding tutorial walks through the setup.

• Deleting a shard key reclaims all resources instantly (no fragmentation, no optimizer overhead)
• Pre-create the next period's shard key before rotation to avoid write disruption
• Use shard_key_selector at query time to search only specific periods for efficiency
• Shard keys can be placed on specific nodes for hot/cold tiering

Collection Rotation (Alias Swap)

Use when: you need per-period collection configuration (e.g., different quantization or storage settings). Collection aliases

Create one collection per period behind a write alias, swap the alias to the new collection when a period starts Switch collection, and drop the oldest collection outside the window. Queries must fan out across all active collections in parallel and merge results client-side.

Trade-off vs shard rotation: allows per-collection config differences, but requires application-level fan-out and more operational overhead.

Filter-and-Delete

Use when: data arrives continuously without clear time boundaries, or you want the simplest setup.

1. Store the timestamp as a datetime payload on every point and index it Payload index
2. Filter to the desired window at query time with a datetime range condition Datetime range
3. Periodically delete expired points using delete-by-filter Delete points

• Run cleanup during off-peak hours in batches (10k-50k points) to avoid optimizer locks
• Deletes are not free: tombstoned points degrade search until optimizer compacts segments
• Does not reclaim disk instantly (compaction is asynchronous)