Known Differences

The FoundationDB Document Layer differs from MongoDB® in several ways. We’ve implemented a number of bug fixes, affordances for new behaviors, and some new features.

We’re prioritizing unimplemented features based on user feedback. If you’re using a feature on this list, please let us know by raising a GitHub issue.

Improvements

No locking for conflicting writes

The Document Layer employs the optimistic concurrency of Key-Value Store. As a result, write operations of any sort do not take locks on the database. Instead, if two operations concurrently attempt to modify the same field of the same document, one of them will fail, and can be retried by the client. (Most operations will automatically retry for a configurable number of times.)

Online index builds

Non-backgrounded index builds do not lock the database, and backgrounded ones are fast and space efficient.

Online index builds in the Document Layer perform the exact same operations whether backgrounded or not – the only difference made by the background parameter in an createIndex operation is whether the command returns to the client and unblocks the connection before the index is ready. In either case, the ongoing index build does not block concurrent database operations, including write operations and other metadata operations, and the index is fully consistent as soon as it is ready for use.

Irrelevant commands removed

Many database commands, including all commands concerning sharding and replication, are not applicable to the Document Layer and are therefore unimplemented.

$explain format

The format of the information returned by the $explain operation is not final, and may change without warning in a future version. It is also substantially different from the format of explanations returned by MongoDB®.

Multikey compound indexes

Multikey compound indexes in the Document Layer permit the document to have array values for more than one of the indexed fields. Care should be taken with this feature, however, as updates to such a document may generate a number of index updates equal to the Cartesian product of the lengths of all of the indexed arrays. Currently, the Document Layer will not permit the insertion or updating of a document which generates more than 1000 updates to a single index in this way. In a future release, we expect this limit to become configurable.

Unimplemented features

Document Layer’s feature set is focused on CRUD operations and indexes. Some of the important features missing are listed here.

Aggregation framework

The Document Layer does not implement the MongoDB® aggregation pipeline and operators.

Sessions

MongoDB® has introduced sessions in v3.6. The Document Layer doesn’t support sessions yet. Sessions in MongoDB® enable better consistency guarantees. It’s important to note that, even though the Document Layer doesn’t support sessions, it has better consistency guarantees by default due to FoundationDB backend.

Oplog (Change Streams)

The Document Layer does not perform async replication and so does not need the Oplog. Future releases may emulate the Oplog to aid migration of applications that directly examine it.

Tailable cursors and capped collections

The Document Layer does not support tailable cursors or capped collections.

Geospatial queries

The Document Layer does not implement any geospatial query operators.

Projection operators

While the Document Layer does support custom projections of query results, it does not support any projection operators. Only literal projection documents (inclusive or exclusive) may be used.

Evaluation operators

The Document Layer does not support the $text or $where query operators.

Sparse indexes

The Document Layer does not support indexes which only contain entries for documents that have the indexed field.

Non-multikey indexes

All indexes in the Document Layer permit multiple entries for a given document if the indexed field on that document contains an array.

Mixed-order compound indexes

Compound indexes in the Document Layer must be either ascending or descending on all of their fields.

Auth/auth

The Document Layer does not support MongoDB® authentication, role-based access control, auditing, or transport encryption, although transport-layer encryption is supported between FoundationDB clients and the Key-Value Store.

We are working on adding TLS very soon.

Deprecated BSON types

The Document Layer does not support the deprecated BSON binary format (binary subtype 2) or the MongoDB® internal timestamp type.

Database references

The Document Layer does not support DBRefs.

Positional operator

The Document Layer does not support the '$' positional operator in updates or projections.

findAndModify command

The Document Layer has disabled the sort parameter to the findAndModify command. For more information, see the Developer Guide.

$push and $pull operators

The Document Layer does not support the $position modifier to the $push operator. The $sort modifier to the $push operator is only available if both the $each modifier and the $slice modifier have been used. Finally, the $pull operator only accepts literal values rather than general query objects.

Database commands

MongoDB® supports a wide range of administrative commands targeted at DBAs and DevOps personnel rather than developers. Where appropriate, the Document Layer supports these commands as well or will implement them in the future.

Behavioral differences

Numeric field names

Use of array-like numeric field names are not supported in non-array BSON documents. The Document Layer does not support the use of array-like numeric field names (e.g. “1”) in non-array BSON documents.

listDatabases command

listDatabases will always return a size of 1000000 bytes for a database that contains any data.

Ordering of fields

The Document Layer ignores the provided order of fields in a BSON document.

The Document Layer ignores the provided order of fields in a BSON document. BSON documents consisting of the same elements in a different order are considered to be equivalent.

One side effect of this is that unlike in MongoDB®, you may not have documents with compound _id fields with identical elements in a different order, (e.g. attempting to insert both {_id:{foo: 1, bar: 1}} and {_id:{bar: 1, foo: 1}} into a collection will result in an error).

Nested $elemMatch predicates

A query document composed of two or more nested $elemMatch predicates may behave differently.

A query document composed of two or more nested $elemMatch predicates, e.g., {'a': {'$elemMatch': {'$elemMatch': {'$gt': 0}}}}, may behave differently than it would if executed in MongoDB®.

Slow query log

The Document Layer logs all operations that perform full collection scans on non-system collections.

Rather than log all operations that take more than a certain amount of time, the Document Layer logs all operations that perform full collection scans on non-system collections. In this way, we hope to warn developers about operations that may become slow when more data is added to a collection.

Protocol differences

Exhaust Mode Queries

In Exhaust Mode, the server generates RequestID values such that they avoid colliding with client-generated RequestID values.

As with MongoDB®, queries in Exhaust mode will be responded to with 1 or more replies. All of the replies will contain a different server-generated RequestID which increases by 1 or more for each subsequent reply. The first reply will also contain a ResponseTo value equal to the RequestID of the client’s original query, while subsequent replies will have ResponseTo set to the generated RequestID of the previous reply.

The Document Layer will generate RequestIDs that are always increasing within a session. However, they are not neccessarily sequential and they are at least 1,000,000 request units ahead of the highest RequestID seen from the client during the session in which the ID is generated. This avoids collision between Client and Server generated RequestIDs.