Starting in MongoDB Enterprise version 3.2.6, the in-memory storage
engine is part of general availability (GA) in the 64-bit builds. Other
than some metadata and diagnostic data, the in-memory storage engine
does not maintain any on-disk data, including configuration data,
indexes, user credentials, etc.

By avoiding disk I/O, the in-memory storage engine allows for more
predictable latency of database operations.

--dbpath, or storage.dbPath if using a configuration
file. Although the in-memory storage engine does not write data to
the filesystem, it maintains in the --dbpath small metadata files
and diagnostic data as well temporary files for building large
indexes.

See inMemory Options for configuration options specific to
this storage engine. Most mongod configuration options are
available for use with in-memory storage engine except for those
options that are related to data persistence, such as journaling or
encryption at rest configuration.

Warning

The in-memory storage engine does not persist data after process shutdown.

The in-memory storage engine is non-persistent and does not write data
to a persistent storage. Non-persisted data includes
application data and system data, such as users, permissions, indexes,
replica set configuration, sharded cluster configuration, etc.

As such, the concept of journal or waiting for data to become
durable does not apply to the in-memory storage engine.

With writeConcernMajorityJournalDefault set to false,
MongoDB does not wait for w:"majority"
writes to be written to the on-disk journal before acknowledging the
writes. As such, majority write operations could
possibly roll back in the event of a transient loss (e.g. crash and
restart) of a majority of nodes in a given replica set.

Write operations that specify a write concern journaled are acknowledged immediately. When an mongod instance
shuts down, either as result of the shutdown command or
due to a system error, recovery of in-memory data is impossible.

With this deployment model, only the mongod instances
running with the in-memory storage engine can become the primary.
Clients connect only to the in-memory storage engine mongod
instances. Even if both mongod instances running in-memory
storage engine crash and restart, they can sync from the member running
WiredTiger. The hidden mongod instance running with
WiredTiger persists the data to disk, including the user data, indexes,
and replication configuration information.

You can deploy mongod instances that use in-memory storage
engine as part of a sharded cluster. For example, in a sharded cluster,
you could have one shard that has consists of the following replica set: