Comparing Fauna and MongoDB
Oct 3rd, 2022|
Categories:
ComparisonFauna 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:
- Multi-Region Deployments
- Sharded Deployments
- Global Clusters
The implication of these limitations is that Atlas Serverless Instances is not suitable for global, data-intensive applications.
Operational model
How Fauna’s operational model improves business outcomes
Fauna is delivered as an API - eliminating the operational load associated with Atlas (capacity planning, managing connections, setting up API infrastructure, sharding manually, etc.) and globally distributed by-default - which offers high availability, auto-replication, and active-active writes. Meanwhile, Fauna offers uncompromised support for enterprise workloads compared to Atlas Serverless (which currently has limitations placed on document size, multi-region transactions, and aggregation functions). Fauna’s unique combination of (uncompromised) global distribution with zero-ops drives increased development velocity and scalability over MongoDB Atlas’ provisioned managed service. Fauna delivers a true serverless experience without sacrificing performance or power.
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.
Data model
How Fauna’s operational model improves business outcomes
Fauna’s document-relational data model and native support for multi-tenancy accommodates shifting access patterns and more dynamic, global applications. Atlas’ provisioned and serverless offerings are limited to documents, with relational functions coming at the cost of performance. The current Atlas Serverless limits impact data model scalability. Instead of having to complement MongoDB with a relational database or migrating entirely, Fauna supports both models, offering flexibility should access patterns evolve or change.
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.
Transactions
How Fauna’s operational model improves business outcomes
While Atlas and Atlas Serverless Instances offer ACID transactions, they only offer serializable transactions - compared to Fauna’s strictly serializable transactions. The implications of this distinction in the context of distributed systems is not trivial, and can lead to serving stale data and transaction reordering. Fauna offers globally distributed ACID transactions by-default. Atlas accommodates distributed/multi-region transactions (without strict serializability), but at the cost of engineering hours and higher latency. Atlas Serverless Instances does not currently support multi-region transactions.
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 ).
Advanced querying
How Fauna’s operational model improves business outcomes
Fauna’s FQL and User Defined Functions allows developers to implement custom business logic in the context of their database. Compared to Mongo and other document databases, this offers a high degree of flexibility and power without sacrificing performance. Mongo Aggregations are defined by several operators and stages; in the event there’s an unpredictable workload, a sophisticated multi-stage aggregation pipeline may lead to performance variance and thus not particularly well-suited for those application patterns with fluctuating demand.
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).
Sharding
How Fauna’s operational model improves business outcomes
The key distinction in the operational load associated with sharding between Fauna and Atlas again amounts to their operational model. Although Atlas has improved the flexibility of its sharding model in recent releases, it still mandates the user to strategize around optimization. Fauna abstracts away these considerations. This again leads to Fauna driving increased development velocity and business value. With Fauna, developers can focus on value-add enhancements to the application, and not shard management.
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.
Security
How Fauna’s operational model improves business outcomes
Users love Fauna’s capacity to control privileges down to the attribute-level without any third party tools. This allows businesses to change access for users in real-time (i.e. if an employee switches departments), and authorize access contingent on the execution of an event (i.e. has the user completed the required training?). This level of granularity reduces the amount of administration needed to control ‘role explosion’, leading to less operational overhead in provisioning authorization.
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
If you enjoyed our blog, and want to work on systems and challenges related to globally distributed systems, and serverless databases, Fauna is hiring
Subscribe to Fauna's newsletter
Get latest blog posts, development tips & tricks, and latest learning material delivered right to your inbox.