Filtered Replication vs View-Based Extraction: Which Minimizes CPU Load During Large Syncs?

Direct Answer

For large, relatively static datasets with stable selection criteria, view-based extraction minimizes source-node CPU during synchronization because filtering work is shifted to incremental view index maintenance (amortized over writes) rather than per-document JavaScript execution during each replication run. Filtered replication remains preferable for ad-hoc or frequently changing filters, small datasets, or when avoiding additional design documents is a priority.

Why View-Based Extraction Usually Wins on CPU

• Filtered replication invokes a sandboxed JavaScript filter function for every candidate document during each replication pass. CPU cost grows linearly with database size and filter complexity, and repeats on every sync.
• View-based extraction runs map functions once per document write/update during index maintenance. The replication phase then becomes a simple _bulk_get or ID-range fetch without per-document JS evaluation.
• Research indicates 60–90% lower source-node CPU during sync for view-based extraction on large, stable datasets (CouchDB 3.x, SpiderMonkey engine).

Trade-offs in Latency and Resource Consumption

Aspect	Filtered Replication	View-Based Extraction
Per-sync CPU (source)	High – JS filter per document	Low – index already built
Write amplification	None	Index maintenance on every write/update
Initial index cost	N/A	One-time spike comparable to a full filtered pass
Replication latency	Single round-trip	Extra round-trip: view query → ID list → replication
Filter flexibility	Ad-hoc, dynamic logic	Stable criteria; changing filter requires index rebuild
Disk overhead	None	10–30% of data size per view index

When Filtered Replication Is Still the Right Choice

• Highly dynamic filters (user-specific, time-windowed, external lookups).
• Small datasets where index maintenance overhead isn’t justified.
• Environments where adding design documents or managing view compaction is undesirable.

Verification Steps (Run in a Test Environment)

1. Enable CouchDB stats: /_node/_local/_stats and monitor cpu, replication, and view_indexer metrics.
2. Sync ~100k+ documents with both methods under identical network/disk conditions.
3. Measure wall-clock time and CPU seconds (e.g., with a benchmark script).
4. Check view index build progress via /_active_tasks during initial creation.
5. Compare replication document rates (docs/sec) and source CPU % in logs.
6. Verify logical equivalence by comparing replicated document counts and spot-checking content.

One Missing Diagnostic Detail

What is the typical rate of document writes/updates relative to sync frequency? If writes are very frequent, view index maintenance cost may shift the CPU burden back to the source node during write peaks, altering the recommendation.

Assumptions and Uncertainty

• Assumes CouchDB 3.x with SpiderMonkey JS engine; behavior may differ on older versions.
• View index compaction schedules and disk I/O patterns are not modeled here.
• Network latency between source and target affects the relative impact of the extra view-query round-trip.
• Complex filter logic (multi-field conditions, external lookups) magnifies the per-document penalty in filtered replication; view map functions can emit compound keys for efficient range queries.