Comparing Fauna and MongoDB

Fauna is a fully serverless, document-relational database that was built from the ground-up to abstract away the undifferentiated operational tasks associated with maintaining and scaling an application. MongoDB was introduced as an on-prem database, followed by the release of its managed cloud service (Atlas) in 2016, and, most recently, the GA of Atlas re-platformed as a serverless offering (MongoDB Atlas Serverless Instances) in June 2022. Fauna and MongoDB’s divergent architectural origins and resultant operational models lead to a fundamentally different developer experience. This blog will review how Fauna’s feature set designed for modern applications and development patterns drives superior business outcomes over MongoDB Atlas and Atlas Serverless Instances.

For a brief side-by-side comparison, visit the Fauna <> MongoDB comparison page.

The core differences between Fauna and the MongoDB offerings can be summarized by the following attributes:

• Fauna has a document-relational data model with both document and relational attributes baked-in; Atlas and Atlas Serverless Instances’ are limited to traditional document models.

• Fauna guarantees strict serializability; Atlas and Atlas Serverless Instances guarantee serializability.

• Fauna is delivered as a global API with zero-ops; Atlas is provisioned and requires manually configuring the database as an application evolves, while Atlas Serverless Instances has scaling limitations.

• Fauna is designed as a public-facing utility with fine-grained access control (ABAC), offering more compatibility with modern applications delivered on the edge through ephemeral functions or with serverless frontends compared to Atlas and Atlas Serverless Instances’ role-based model (RBAC).

• Fauna is accessed through an HTTP call from anywhere around the globe; Atlas is accessed via TCP/IP and Atlas Serverless Instances is not globally distributed.

• Fauna is distributed by default; Atlas must be configured to accommodate multi-region workloads and comes with performance costs, while Atlas Serverless Instances is single-region.

• AuthN and many AuthZ features are baked into Fauna and reduce the amount of custom building required. Atlas and Atlas Serverless Instances require additional configuration.

Fauna eliminates the need to address the maintenance and scalability questions inherent in MongoDB Atlas (e.g., reasoning around transactionality in a distributed system, unfolding downstream effects of duplicating data to ensure performance, etc.), or work around the immaturity and constraints of MongoDB Atlas Serverless Instances. When evaluating MongoDB, it’s imperative to consider the second and third-order effects of how a data model might evolve over time and how the application’s incumbent performance, availability, and consistency objectives will be maintained accordingly. One of MongoDB’s deployment models (on-prem, Atlas, or Atlas Serverless Instances) may accommodate an application’s requirements today - but developers will also need to think through capacity planning, sharding strategy, multi-region expansion challenges, data model flexibility, or some combination thereof depending on the deployment model, should their current requirements or access patterns ever change. Fauna delivers the elasticity to scale and adapt on-demand without the mental or financial overhead associated with planning for those changes. Fauna’s operational and data model flexibility combined with its global consistency and distribution lends itself to net-new application development, modernizing an existing application, or complementing a legacy application where the underlying database must be able to handle a heavy global transactional load, yet be flexible enough to adapt as an application evolves.

Attribute comparison at a glance

Before diving into an in-depth analysis of the operational and architectural differences between MongoDB and Fauna, we will begin with an abbreviated summary of the core attributes of Fauna, MongoDB Atlas, and Atlas Serverless Instances, and how differences in those attributes impact business outcomes.

Developer experience and business outcomes

Database selection is driven by business requirements. Fauna was designed for use cases and scenarios where speed (both in application latency and development velocity) and accuracy are critical. While MongoDB can be engineered to accommodate some of the features that are delivered out-of-the-box with Fauna, it comes at the cost of developers’ time and attention and at the risk of having to re-engineer the database in the future. There are other Fauna attributes that MongoDB cannot replicate: Fauna’s document-relational data model, delivery via global API, strict serializability, active-active writes, and global distribution by-default. For those scenarios where consistency, distribution, and scalability are top-level considerations, Fauna delivers the requisite performance criteria without the operational burden you get in a managed service offering like MongoDB. Continue reading for a deeper dive into how the attributes introduced above make Fauna a better choice for modern workloads.

“With Fauna we can scale without impacting our application code and don’t have to worry about the cost and effort that are required to scale a traditional cloud database.” – Kevin Ho, CEO, Insights GG

Operational model

Fauna

Delivered as a global API; multi-region distribution by-default and auto-replication

Fauna manages sharding, scaling, capacity planning, provisioning, upgrades, connections, replication, and other operational tasks without sacrificing consistency, performance or availability.

Further, Fauna is distributed by-default; which results in high availability/redundancy, low latency, and auto-replication. Fauna offers active-active writes natively in a masterless architecture - each replica and node across the globe is capable of confirming writes, ensuring that not only reads but write latency stays consistent across all regions. Fauna doesn’t come with the scalability, single-table design, or ACID-compliance concessions of re-platformed serverless models like Atlas Serverless Instances, while achieving the powerful querying capabilities and strong horizontal scaling/multi-region capabilities offered by Atlas. Although Atlas is a managed service, users still need to specify the nodes required in a cluster, and think through the implications on the server and memory. With Fauna, developers are able to achieve a more coherent mental model of how they think and code through Fauna’s JSON-modeled documents, compared to Atlas where the developer will have to reason around instances.

Fauna’s connectionless and secure HTTP-based model abstracts away the need to orient around connection pooling. Fauna was purpose-built to serve as a data utility for modern applications accessed over the internet - leading to performant and dynamic applications.

Atlas

Managed Cloud/Database as a Service

Atlas is delivered as a provisioned cloud service, which definitionally mandates reasoning around connection pooling, clustering strategy, and other operational considerations. Atlas is designed to scale horizontally, but needs to be configured to accommodate global applications. This means that developers need to consistently plan for potential downstream implications depending on how an application evolves.

In contrast to Fauna’s distributed active-active nature, Atlas has primary/secondary replicas, and active-passive writes as a result. The implication of this is that a “replica set can have only one primary capable of confirming writes.” Active-active writes are not possible in Atlas, which may result in write latency in global applications.

Managing connection pools with serverless (and ephemeral) front-ends mandates work-arounds to maintain performance and low costs. When connecting with a client through an HTTP request (i.e. in the example of a serverless or mobile application), Atlas offers an API layer managed through the Atlas App Services - their Data API. Mongo’s Data API “is not a direct connection to your database”; instead, Atlas App Services serves as a “fully-managed middleware layer”. This results in customers needing to navigate another layer of infrastructure in their deployment, or accepting performance concessions; Mongo suggests that for “high-load use-cases and latency sensitive applications we recommend connecting directly to your database with a MongoDB driver” and avoiding the Data API.

This illustrates a recurring theme when comparing Fauna and Atlas - while Atlas has introduced features like the Data API that make it possible to interface with modern architectures, its underlying design runs counter to these scenarios - and thus concessions must be made. The concepts of API routing and orchestration simply don’t exist in Fauna; Fauna itself acts as an API and was designed to be internet-facing.

Atlas Serverless Instances

Serverless; single-region

Atlas Serverless Instances intends to follow the serverless ethos of removing the operational burden associated with database maintenance and scalability, but is a nascent offering and comes with a number of performance & operational constraints that limit its suitability for enterprise workloads.

The following configurations are not currently offered in Serverless Instances:

1. Multi-Region Deployments
2. Sharded Deployments
3. Global Clusters

The implication of these limitations is that Atlas Serverless Instances is not suitable for global, data-intensive applications.

Data model

Fauna

Document-relational

Fauna combines the flexibility & horizontal scalability of a NoSQL/document database without sacrificing the security, joins, unique constraints, and user-defined functions offered in an RDBMS. In other words, developers can reason about their data like they do with a NoSQL database, while getting the support and power of an RDBMS. Front-end developers can get started with ease (with easier mapping between back-end and front-end logic) and avoid the trade-offs associated with the classic binary relational/NoSQL paradigm through its ability to perform complex data modeling and queries using compute in the database.

Atlas

Document

Atlas supports denormalized data structures and has a flexible schema at the document and collection levels. The Atlas data model is oriented around the notion that ‘what is accessed together is often best stored together.’ While the flexibility inherent in the document model comes with many benefits, the reality is that there are scenarios in which robust relational features add significant value, and Atlas is not designed for these scenarios.

Atlas has released some relational-like features in recent releases. In release 4.2, MongoDB announced Aggregation Pipelines, which represent one or more ‘stages’ that process documents and allows users to query from multiple collections: “Each stage performs an operation on the input documents. For example, a stage can filter documents, group documents, and calculate values.” In release 5.0, MongoDB announced ‘Cross-shard joins and graph traversals’; their $lookup and $grahplookup features ‘‘combine and analyze data that is distributed across shards which was not previously possible.’ While MongoDB has introduced features like cross-shard joins that allows developers to perform some relational-like actions, they still fall short of Fauna’s rich compute layer and require additional mental horsepower.

Atlas Serverless Instances

Document

Replication of MongoDB Atlas albeit with performance & operational constraints.

Transactions

Fauna

Fauna’s Calvin inspired transaction log provides strong consistency and multi-region replication so application code doesn’t have to. Everything in Fauna is a transaction. Transactions are made durable in a partitioned, replicated, strongly-consistent statement-based log. Data replicas apply transaction statements from the log in deterministic order, guaranteeing ACID properties without additional coordination. For use cases where distributed transactionality is critical, Fauna eliminates the burden of having to reason about transactionality.

Fauna’s active-active writes and strict serializability are purpose-built for distributed and modern architectures.

Atlas

Atlas uses a ‘locks’ system to enforce transactionality across reads and writes. Read and write concerns allow users to set levels to “control the consistency and isolation properties of the data read from your replica sets. Finding the right values for the read and write concerns is pivotal as your application evolves and with the latest release of MongoDB adding global read isolation and write durability defaults is now possible.” Write concerns do not apply to replicas.

From the MongoDB documentation: “MongoDB uses locking and concurrency control to prevent clients from modifying the same data simultaneously. Writes to a single document occur either in full or not at all, and clients always see consistent data.”

Mongo introduced ‘Distributed Transactions’ in release 4.2, which “added support for multi-document transactions on sharded clusters and incorporates the existing support for multi-document transactions on replica sets.” With that said, Mongo warns that in “most cases, multi-document transactions incurs a greater performance cost over single document writes, and the availability of multi-document transactions should not be a replacement for effective schema design.” Atlas’ transactional profile reflects other core limitations of the managed service model; while it’s possible to achieve distributed transactions, they come at a cost.

Atlas Serverless Instances

Atlas Serverless Instances has limited documentation publicly available on transaction guarantees outside of volume limitations and distribution: “Serverless instances support multi-document transactions that are up to 700 MB in size. Atlas aborts any serverless instance transactions that exceed 700 MB.” Atlas Serverless Instances does not currently support multi-region transactions.

Outside of this constraint, it is assumed that transactions on Serverless Instances possess similar attributes to MongoDB Atlas.

Advanced querying

Fauna

For advanced queries, Fauna offers the expression-oriented Fauna Query Language (FQL). FQL supports common application-level constructs such as variables, loops and conditional logic and a rich set of functional programming and relational database utilities such as map, filter, union, join, distinct, etc. While not a general purpose programming language, FQL provides much of the functionality expected from one, allowing for complex, precise manipulation and retrieval of data stored within your database. Functions, also known as user-defined functions (or UDFs), provide a mechanism to store and run commonly used Fauna queries.

FQL operates primarily on the schema types provided by Fauna, which include documents, collections, indexes, sets, and databases.

Atlas

Atlas offers a GraphQL API and three native functions: a map-reduce function, single-purpose aggregation, and the aggregation pipeline, a “multi-stage pipeline that transforms the documents into aggregated results.”

Atlas’ aggregation pipelines are powerful and intuitive but also must be carefully manipulated and managed to avoid negative impacts to execution and latency performance.

Atlas has a $function operation, which “defines a custom aggregation function or expression in JavaScript.” However, Mongo concedes that “executing JavaScript inside an aggregation expression may decrease performance. Only use the $function operator if the provided pipeline operators cannot fulfill your application's needs.”

Atlas’ pipelines also comes with volume limitations of “100MB of RAM.” To accommodate larger datasets, users can set the allowDiskUse option to true - however this can lead to higher latency and execution time as the additional data is stored on disc.

Atlas Serverless Instances

We were unable to identify documentation demarcating the Serverless Instances querying capabilities - it is assumed that Atlas Serverless Instances reflects the core Atlas query functionality, with the following constraints: “Serverless instances don't support the allowDiscUse option for the aggregation command, its helper method, or the cursor.allowDiskUse()query cursor method.”

The above caveat translates to not supporting a pipeline stage involving over 100MB of RAM. Serverless Instances also doesn’t support a handful of pipeline stages included in Atlas ($currentOp, $listLocalSessions, $listSessions, and $planCacheStats ).

Sharding

Fauna

Sharding is executed out-of-the-box in Fauna. Instead of needing to design and implement a sharding strategy or maintain a custom shard key, Fauna manages all of this on the customer’s behalf. The need to reason around how data is distributed and related amongst different shards does not exist in Fauna. Whereas a developer in MongoDB and other databases would need to allocate time to designing a dynamic sharding strategy that works both in the current state and the future, Fauna users can focus on delivering a better user experience and not backend mechanics.

Atlas

While Atlas no longer limits customers to a unique shard key in perpetuity (customers can change their shard key beginning in release 5.0), they acknowledge that “ the choice of shard key affects the performance, efficiency, and scalability of a sharded cluster. A cluster with the best possible hardware and infrastructure can be bottlenecked by the choice of shard key.”

Mongo acknowledges the performance limitations of sharded clusters. From the MongoDB documentation: “Transactions that affect multiple shards incur a greater performance cost.” Sharding in MongoDB Atlas, in this sense, requires planning, management, and maintenance.

Atlas Serverless Instances

Delivered out-of-the-box, but with performance and operational constraints (Serverless Instances does not accommodate Sharded Deployments or Global Clusters).

Security

Fauna

Fauna offers fine-grained ABAC (Attribute-Based Access Control)-level security down to the document level, and Auth0 integration. Fauna was designed as a public-facing API, with the type of fine-grained security you would expect in internet-native or API-first architectures. You can confidently access the Fauna API anywhere with one of its drivers.

Atlas

Atlas offers RBAC (Role-Based Access Control) - assigning permissions based on roles. For modern architectures designed to be internet-first, RBAC is a less suitable model than ABAC. RBAC policies are intended to be static, and unable to adapt contextually - i.e. based on the location or time of day.

Atlas Serverless Instances

We could not identify documentation demarcating serverless security features - it is assumed that Atlas Serverless Instances reflects the Atlas security profile.

Conclusion

MongoDB is undoubtedly a powerful and performant database. With that said, Fauna’s base cases are MongoDB’s outlier cases: applications with changing access patterns, scaling from single to multi-region without configuration, or that require strict serializability. Customers looking to build performant applications with zero-ops, global distribution, ACID compliance, and powerful relations should look to Fauna.

“Fauna is a “fire and forget” globally distributed database. We’ve tried them all and only Fauna was truly serverless.” - Will Kimbell, CTO/Architect, Connexin