For AI agents: the complete documentation index is available at https://silt-db.dev/llms.txt, the full documentation bundle is available at https://silt-db.dev/llms-full.txt, and this page is available as Markdown at https://silt-db.dev/reference/compatibility.md.

MongoDB compatibility

Silt is an embedded MongoDB alternative: @silt-db/mongodb runs a MongoDB-compatible JavaScript API in your application process, with SQLite providing storage and query execution. Supported application code can reuse its collection operations, filters, pipelines, and updates after changing the import and initialization. Silt is prerelease; check the limits below against the code you intend to run.

For API usage and query syntax, use the official MongoDB Node driver documentation. Silt's references describe supported operations and differences:

AreaSilt reference
Client, collections, cursors, sessions, accepted options and resultsDriver API and options
Query predicatesQuery support
Aggregation stages, accumulators and joinsPipeline support
Aggregation expressionsExpression support
Update operators, pipelines and array filtersUpdate support
Portable regex and optional native PCRE2Regex support

Limits to check first

AreaCurrent boundary
Data modelPlain JSON objects containing finite numbers, strings, booleans, null, arrays and nested plain objects. Missing fields remain distinct from explicit null; embedded-object field order matters for equality.
BSONNo ObjectId, Date, Decimal128, Binary, BSON regular expressions, timestamps, MinKey/MaxKey, or numeric subtype identity. Unsupported JavaScript/BSON values fail validation. A date converted to a string has string semantics.
IDsPersistent unique _id; a UUID string is generated when absent. Scalar and valid embedded-object IDs are supported; array IDs are rejected. Non-string IDs use semantic uniqueness checks and conservative reads.
NumbersComputed values depend on SQLite. BSON numeric promotion and exact decimal arithmetic are absent; long conversion is restricted to safe JavaScript integers. Original JSON tokens are preserved when copying values. Tested Expo SQLite 3.50.3 has extreme-double parsing/formatting defects; see numeric precision.
DatabasesOne SQLite file is one database. client.db() and client.db(configuredName) use that database; other names reject. dbName defaults to test and is a label, not a storage namespace. Separate databases need separate files.
IndexesPersistent nonunique compound and multikey indexes, plus _id uniqueness. No unique secondary, text, geo, TTL, sparse, or partial indexes. Index eligibility and query plans differ from MongoDB.
Queries and aggregationOnly listed operators and operand forms are supported. Notable omissions include text/geospatial queries, $where, $jsonSchema, window/graph stages, $out, $merge, and statistical/percentile accumulators.
UpdatesSupported modifiers, update pipelines, $[], and $[identifier] array filters. Legacy positional $, $currentDate, and potentially overlapping positional paths reject. A narrow final-JSON modifiedCount difference is documented in updates.
RegexDefault SQL matcher has a limited grammar and no case-insensitive flag, captures, or lookaround. Broader PCRE2 support requires an explicitly enabled native Node extension.
SessionsLocal SQLite transactions, with explicit session routing. No automatic transaction callback retry, causal clock, retryable-write protocol, or distributed transactions.
Server featuresNo MongoDB wire protocol, network URI connections, authentication, server commands/administration, replication/sharding API, GridFS, change streams, collection rename, or BSON serialization API. Silt cannot replace arbitrary dependencies on the official mongodb package.
Options and errorsUnknown options reject, including read/write concern, read preference, locale collation, hints, server timeouts and unsupported cursor flags. Error classes, codes, timing, and resource limits are not fully reproduced.

Unsupported syntax normally throws SILT_UNSUPPORTED, SILT_VALIDATION, or a driver compatibility error. Document-dependent invalid values abort execution in SQLite and can surface as malformed JSON. There is no JavaScript query fallback.

Execution and storage differences

Mongo API insertMany, bulkWrite, and updateMany preserve earlier successful writes outside a transaction when a later write fails. A failing batch inside an explicit transaction rolls back that transaction. The lower-level core API keeps insertMany and updateMany atomic across the operation. Mongo API updateMany currently retains candidate IDs in O(matches) JavaScript memory; filtering and update transformations run in SQL.

Mongo and core APIs share ordinary document collections and indexes. dropDatabase() removes those collections while preserving the SQLite file, ShareDB snapshot/operation tables, and custom SQL/BLOB tables. ShareDB provides its own operation/subscription integration and requires shared PubSub for notifications across backend processes.

Portable cursors page SQLite TEMP results; server cursors lease WAL readers. Rows are decoded lazily, while toArray() collects all remaining results in JavaScript. SQLite may materialize intermediate results. Compound-value sorting can require O(n²) ranking, and unindexed correlated lookups can scan the foreign collection for every local row. SQLite parser, nesting, and resource limits apply.

Owned server files default to WAL and full synchronous durability; borrowed connections retain caller configuration. Tested Expo browser persistence uses OPFS with DELETE journaling. Node and Expo web execution have validation evidence; native Expo device runtime execution remains a separate, uncompleted gate.

Compatibility evidence

MongoDB is the semantic authority. Existing hosted CI results cover exercised query, pipeline, update, driver API, and transaction comparisons against MongoDB 8.0.29 and 8.3.8; captured fixtures retain their recorded provenance. These results establish the tested cases, not complete MongoDB parity. See testing and actual results for versions, reproduction, and validation scope.