Skip to content
NoSqlStudio
Documentation

Multi-DB Indexes

NoSqlStudio runs Atlas-grade features on backends that do not implement them natively. $search, $vectorSearch, CSFLE, and time-series work on AWS DocumentDB and Azure Cosmos DB via local engines.

What it is

A workspace tab that manages local search / vector / CSFLE / time-series engines layered on top of any Mongo-API backend (Atlas, DocumentDB, Cosmos, self-hosted). When you target DocumentDB or Cosmos and need $search, the local engine handles the request and persists state under userData/MultiDb/, exposing the same aggregation operators MongoDB Atlas would.

When to use

When you are forced to run on DocumentDB or Cosmos for compliance / cloud-vendor reasons but still need full-text search, vector search, CSFLE encryption, or time-series collections — features those backends do not natively implement. NoSqlStudio brings them locally without changing the data plane.

How to open

  1. In the NoSqlStudio desktop app, open the Tools menu → Multi-DB Indexes, or press Ctrl+Alt+Shift+U.
  2. The workspace lists configured engines per connection: Search, Vector Search, CSFLE, Time-Series.
  3. Connect to a DocumentDB or Cosmos cluster — the flavour detector auto-recognizes it and flags which Atlas operators are missing.

Each engine

  • Search — local Lucene-style index built from your collection. Supports $search with text, autocomplete, fuzzy, and basic filters. Index data lives under userData; queries route through the local engine.
  • Vector Search — local HNSW index. Supports $vectorSearch with k-NN and cosine / euclidean distance. Compatible with the same query shape Atlas expects.
  • CSFLE — Client-Side Field-Level Encryption. Local keystore + key derivation. Documents encrypted at the driver; the backend sees ciphertext only.
  • Time-Series — local time-series wrapper that mimics MongoDB 5.0+ time-series collections on backends that do not implement them. Granularity, metaField, bucketing all configurable.

Limitations (v1)

  • Engines run in the desktop app process. For server-side workloads (background jobs reading the search index), you must shell out via the local API or run a sidecar that talks to the same local engine.
  • Index size is bounded by your workstation's disk. For multi-TB datasets, consider whether Atlas-native is the better path.
  • Search-result re-ranking and CSFLE auto-decryption are best-effort interleaved with the upstream backend's aggregation pipeline. Complex pipelines mixing $search + $lookup + $facet may produce ordering differences from a pure Atlas run.