Query everything. Reprocess nothing.

iterateChangesSince() is the single foundation for Virtual Views, fulltext search, external system sync, and custom analytics. Learn one API, unlock all querying patterns.

Virtual Views span multiple databases within a tenant, across tenants, or mix local and remote data — without moving documents. Ideal for consolidated dashboards and cross-organization reporting.

The append-only store preserves every change. Query any past state, compare document evolution over time, create point-in-time database snapshots, and build complete audit trails — all from the same data.

• Cursor-based — pass null for initial scan, then the last returned cursor for incremental updates
• Modification order — documents yielded oldest-change-first, so indexes see consistent progression
• Deletion-aware — deleted documents appear with isDeleted() flag for clean removal from indexes
• Consumer-driven batching — async generator lets you stop at any point and resume later

• O(changed) — each incremental run processes only documents modified since the last cursor
• No full scans — the internal index tracks (lastModified, docId) for efficient cursor resumption
• Pluggable consumers — one change stream can feed multiple indexers in a single pass
• Works offline — indexes update locally; sync brings in remote changes, then indexers process the delta

• Category columns — group documents into nested hierarchies (e.g. Department > Year > Quarter)
• Sorted columns — sort entries within each category by one or more fields
• Total columns — automatic SUM or AVERAGE per category, updated incrementally
• Display columns — additional data shown alongside each entry
• Value functions — compute column values dynamically from document data

• Expand/collapse — drill into categories or collapse them, like a file explorer
• Position-based navigation — jump to "1.2.3" (first category, second sub-category, third entry)
• Selection — select individual entries or entire categories for batch operations
• Access control callbacks — filter visible entries per user without changing the view structure
• Forward and backward iteration — traverse the tree in either direction

Combine a US products database and an EU products database into a single product catalog. The view categorizes and sorts across both sources. Each entry carries its origin, so your UI can show the source region.

Span views across different MindooTenants for cross-organization reporting. Two organizations share data in a third tenant; a consolidated view aggregates revenue across all three — each tenant retains independent admin control.

Each data provider tracks its own cursor independently. Calling view.update() processes only documents that changed in each source since the last run. You can also update a single origin with view.updateOrigin("us-products").

Client-side fulltext search is the natural complement to end-to-end encryption. Documents are decrypted locally, then fed into a search index that runs entirely on the client — no plaintext ever reaches the server.

• FlexSearch — high-performance, memory-efficient, incremental
• MiniSearch — lightweight alternative with fuzzy matching
• Lunr.js — client-side search with language support
• Custom indexers — any system that supports add/update/remove

Build data pipelines that react to document changes. The async generator pattern means you can process changes at your own pace, with backpressure built in.

• Analytics feeds — push aggregated metrics to dashboards
• Webhook triggers — notify external systems when specific documents change
• ETL pipelines — extract and transform data for reporting systems
• Replication — mirror data to secondary systems with exactly-once semantics

• getDocumentAtTimestamp() — retrieve a document snapshot at any past timestamp, applying all changes up to that moment
• getAllDocumentIdsAtTimestamp() — efficiently get all document IDs that existed at a specific time, without loading content
• Deleted document handling — distinguishes between "didn't exist yet" (returns null) and "was deleted" (returns doc with isDeleted() flag)

• iterateDocumentHistory() — walk through every change from creation to current state, in chronological order
• Author metadata — each change includes timestamp and the public signing key of the user who made it
• Independent clones — each yielded document version is an independent snapshot, safe to store and compare
• Change detection — only yields when the document actually changed (skips no-op updates)

Create a frozen copy of your database at the end of each fiscal quarter. Auditors can independently verify document states, authorship signatures, and change history — all cryptographically provable.

Compare document sets at two timestamps to find what was created, modified, or deleted in between. Combine with getDocumentAtTimestamp() to see exactly how individual documents evolved.

Run the same Virtual View or query against database snapshots at different dates. Compare results month-over-month or quarter-over-quarter without maintaining separate reporting databases.

In MindooDB, document content is end-to-end encrypted. The server stores only ciphertext and cannot execute queries. This is a deliberate security tradeoff: confidentiality over server-side convenience. Client-side indexing restores the querying capabilities you expect — with the guarantee that your data is never exposed to the server.

The incremental approach keeps this practical at scale. Instead of rebuilding indexes from scratch after each sync, the cursor picks up exactly where it left off, processing only the delta. For a database with 100,000 documents where 50 changed since the last sync, the indexer processes 50 documents — not 100,000.

MindooDB's append-only store is what makes all these patterns possible. Because changes are never overwritten:

• Cursors are stable — the modification order doesn't change, so resuming from a cursor is always consistent
• Time travel is free — the full history is already stored; no additional logging or snapshots needed
• Audit trails are built in — every change is signed and timestamped by its author
• Incremental updates are correct — the change stream is complete and ordered; no missed updates

This stands in contrast to mutable databases where implementing change tracking, history, and incremental indexing requires additional infrastructure (WAL, CDC, change streams, audit tables).