Flexibility of DynamoDB vs flexibility of Fauna

DynamoDB is a key-value store that recommends a single table design to avoid design limitations in accessing multiple tables to ensure predictable performance. Developers are required to define all data access patterns and local secondary indexes at the time of table creation; any change requires transitioning data to a new table. Such transitions become difficult if additional global secondary indexes are required. Multi-item cross table transactions and complex queries or joins are not supported. New application features added post table creation can create extensive model rework, added friction to the development process and slow time to market of new features. DynamoDB has limited and complex indexing options with a limit of 25 indexes per table (5 local secondary indexes and 20 secondary indexes). Global secondary indexes cannot index sub-documents or arrays and local secondary indexes cannot be modified after initial table creation. Querying options are also significantly limited to key-value queries. AWS services such as Redshift and Elastic MapReduce can be used but increase cost, latency and complexity, since it involves using other paid services to further manipulate data.

Unlike DynamoDB, Fauna is a document-relational database which combines the flexibility of JSON documents with the relationships and querying power of a traditional relational database. The flexible model supports unstructured data, foreign keys, views and joins and supports normalization and efficient access across collections in a single query. No upfront table design or extensive model rework required when data access patterns change. Fauna supports creating indexes to any field in a document with full support for secondary indexes.The model supports indexing types such as compound, TTL, hash, wildcard, text, array, etc. The indexes are strongly consistent with the underlying data. Fauna’s powerful native query language, FQL, enables users to aggregate and query data natively in multiple ways, such as single keys, ranges, graph traversals, joins, etc. Developers can express business logic in user-defined functions that execute as fully transactional requests in the context of their data. Guaranteed data correctness and consistency means you don’t have to build logic in your app to account for eventually consistent reads.

Rigid vs. flexible data model

DynamoDB is a key-value store and not a full document database.

• Rigid single table design requires developers model their data access patterns in advance resulting in a model that is narrowly tailored for an exact purpose at the time of creation.
• Application changes that impact pre-wired data access patterns result in extensive table rework, added friction to the development process and slow time to market of new features.
• Key-value store model best suited for simple query and high read/write use cases, but lack support for multi-item cross table transactions or when complex queries or joins are required.

Fauna has a flexible document-relational model.

• Flexible document-relational model that supports unstructured data, foreign keys, views, and joins
• Supports normalization and efficient access across collections in a single query
• Event based streaming for real-time data changes at both document and collection level with native attribute-based access control enabling organizations to apply dynamic access control for critical data

Limited vs. flexible indexing

DynamoDB indexes are limited and complex.

• Limited to 20 mutable global secondary indexes per table; requires AWS support to lift the limit if possible
• Limited to 5 local indexes which cannot be modified after initial table creation, forces developers to recreate tables and deal with the side effects of chages to downstream replicas
• Global secondary indexes can only be declared on top level elements and cannot index sub-documents or arrays, making complex queries impossible.
• Global secondary indexes require additional read/write capacity provisioned leading to additional costs.

Fauna supports creating indexes to any field in a document with full support for secondary indexes.

• Fauna supports different indexing types such as compound, TTL, hash, wildcard, text, array, etc. The indexes are strongly consistent with the underlying data.
• Adding indexes and iterating on the data model is much easier because Fauna simplifies handling more complex schemas, reducing data duplication and session size (improves cost & performance)

Limited vs. powerful querying capabilities

DynamoDB has limited native support for key-value queries.

• DynamoDB has a limited query language compared to Fauna. Every DynamoDB record has two keys: a partition key and a sort key. Every query must provide one partition key, and can optionally specify a single value or a range for the sort key.
• DynamoDB natively supports only key-value queries yet allows users to carry out complex aggregations using other AWS services such as Amazon Redshift and Elastic MapReduce. However, using these different services increases cost, latency and complexity

Fauna has a powerful native query language.

• Unlike DynamoDB, Fauna offers a powerful native query language with flexibility in querying data as it enables users to aggregate and query data natively in multiple ways, such as single keys, ranges, graph traversals, joins, etc.
• Define and execute business logic in the context of your data: Powerful native query language (FQL) enables developers to express business logic in user-defined functions that execute as fully transactional requests in the context of your data.
• Guarantees data correctness and consistency so you don’t have to build that logic in your app
• Execute business logic at the database in a single transactional request (Programmable compute environment running in the database using flexible query capability)
• Database programming language that can encode powerful business logic in user-defined functions

Multi-region with DynamoDB vs multi-region with Fauna

DynamoDB tables, by default, are deployed to a single region. To achieve a multi-region deployment a global DynamoDB table is required. In global tables, each region has an identical yet independent table (each charged separately) and all such tables are linked through an automated asynchronous replication mechanism. However, this approach suffers from the same unpredictable last-writer-wins conflict resolution challenge that traditional multi-master database deployments suffer from. Concurrent writes across regions will lead to data loss and reads cannot be strongly consistent across those regions. Enabling global replication requires implementing both Amazon Streams and global tables which add additional developer complexity and cost. Strongly consistent reads are limited to a single region only and are 2X expensive. Additional DynamodB On-Demand capacity mode and auto scaling costs along with Clusters required to replicate across multiple regions can increase capacity cost by 50% or more. If your application has low latency and geo-distributed requirements DynamoDB becomes a cost-prohibitive choice that also slows down release velocity. Managing and changing global replicas may also incur delays; this includes scenarios when replicas are to be deleted or when changing read/write capacity provisioning.

Unlike DynamoDB, Fauna is distributed-by-default and scales seamlessly from single to multi-region while maintaining ACID compliance. A Calvin-inspired transaction engine provides consistent, multi-region replication. All databases created are immediately replicated across three geographic regions within a chosen Region Group. Architecturally, Fauna offers multiple region group options. In each region group the data is replicated while offering ACID compliance. Geographically distributed storage ensures low latency local access and data resilience. Fauna’s customer-proven and Jepsen-tested distributed-by-default design increases reliability and decreases latency for your users. Each database within Fauna has a globally unique ID. Fauna provides developers with a single endpoint, db.fauna.com, to access any and all databases across Fauna’s global footprint. No client configuration changes are required. Intelligent Routing makes sure requests are routed to the closest Fauna node to serve that request. There is no separate pricing scheme for single- vs multi-region with Fauna since your databases are always multi-region – providing you straightforward and transparent pricing.

DynamoDB's global tables model vs. Fauna's globally distributed-by-default model

DynamoDB has complex and costly global tables.

• By default, DynamoDB tables are deployed to a single region. To achieve multi-region deployment a global DynamoDB table has to be created.
• In global tables, each region has an identical yet independent table (each charged separately) and all such tables are linked through an automated asynchronous replication mechanism, thus leading to the notion of a “Global Table”. However, this approach suffers from the same unpredictable last-writer-wins conflict resolution challenge that traditional multi-master database deployments suffer from. Concurrent writes across regions will lead to data loss and reads cannot be strongly consistent across those regions.

Fauna is distributed by default.

• Scale seamlessly while being ACID compliant. Distributed-by-default design increases reliability and decreases latency for your users.
• Calvin-inspired transaction log provides consistent, multi-region replication
• Distributed ACID transaction engine for data correctness and consistency
• All databases created are immediately replicated across three geographic regions within a chosen Region Group. Architecturally, Fauna offers multiple region group options. In each region group the data is replicated while offering ACID compliance.
• Geographically distributed storage to ensure low latency local access and data resilience

DynamoDB's global replication vs. Fauna's single global endpoint with intelligent routing

Enabling global replication in DynamoDB requires implementing Amazon Streams and global tables which adds additional developer complexity and cost.

• DynamoDB data is located in a single region by default and replicates to three availability zones there.
• For multi-region replication, Amazon streams must be enabled. However, DynamoDB limits the number of tables in an AWS region to 256.
• You also need to setup the global tables.

Fauna is multi-region-distributed by default — every database you create is replicated and distributed across geographic regions.

• Each databases within Fauna has a globally unique ID.
• Fauna provides developers with a single endpoint, db.fauna.com, to access any and all databases across Fauna’s global footprint. No client configuration changes required.
• Intelligent Routing makes sure requests are routed to the closest Fauna node to serve that request.
• Fauna’s strongly consistent, multi-region distributed architecture combined with Intelligent Routing protects against regional cloud failures by routing requests to a database replica in a region with no failures while staying compliant with data residency requirements.
• There is no separate pricing scheme for single- vs multi-region with Fauna since your databases are always multi-region.

DynamoDB's eventual consistency vs. Fauna's strong consistency across regions

DynamoDB supports ACID transactions, but they are limited to a single region only, have several restrictions, and drive additional costs.

• If your application has low latency and geo-distributed requirements DynamoDB becomes a cost-prohibitive choice that also slows down release velocity.
• ACID transactions are limited to single region tables only
• Are restricted to a maximum of 10 items or 4MB of data
• No support for client-controlled transactions
• No support for strongly consistent secondary indexes even though transactions are supported.
• Transactional guarantees apply only within the region where the right is made originally.
• If you have a global table with replicas in the US East (Ohio) and US West (Oregon) regions and perform a TransactWriteItems operation in the US East (N. Virginia) Region, you may observe partially completed transactions in US West (Oregon) Region as changes are replicated.
• Changes will only be replicated to other regions once they have been committed in the source region.
• DynamoDB performs two underlying reads or writes of every item in the transaction, one to prepare the transaction and one to commit the transaction.
• You should plan your costs, capacity, and performance needs assuming each transactional read performs two reads and each transactional write performs two writes.

To enable DynamoDB ACID Transactions within a single region DynamoDB recommends:

• Enabling automatic scaling on your tables, or ensure that you have provisioned enough throughput capacity to perform the two read or write operations for every item in your transaction.
• Don't group operations together in a transaction if it's not necessary. For example, if a single transaction with 10 operations can be broken up into multiple transactions without compromising the application correctness, we recommend splitting up the transaction. Simpler transactions improve throughput and are more likely to succeed.
• Multiple transactions updating the same items simultaneously can cause conflicts that cancel the transactions. We recommend following DynamoDB best practices for data modeling to minimize such conflicts.

Fauna provides the strongest consistency guarantees across regions.

• Unlike DynamoDB, Fauna provides guaranteed best in class transactional performance consistency levels for single region, multi-region and global use cases
• Distributed ACID transaction engine for data correctness and consistency
• Guarantees data correctness and consistency so you don’t have to build that logic in your app
• Every FQL query is a executed as a transaction
• ACID guarantees strict serializability of transactions guarantees safe and expected processing of data.
• Jepsen tested

Dev productivity and total cost of ownership in DynamoDB vs. Fauna

In DynamoDB, everything is managed as a table. When requiring access to multiple key-value entities within a table, users are instructed to combine as many of the entities possible into a single table. This single table design paradigm leads to complex yet limited ways to reason and query your data. Further, if data needs to be further manipulated or computed upon,such computations must be done in application code. More application code required leads to more code maintenance, hence lower developer productivity. When creating global secondary indexes and global tables, DynamoDB users are forced to maintain and pay for additional copies of their data tables, while contending with eventual consistency (at their lowest cost, which still multiplies the cost of writes) or seek higher consistency at even higher costs. Even when combining entities in a single table, or using up one of the limited indexes, developers may have to create code that retrieves data in multiple round trip requests, or load data into different tables or data stores while manually maintaining references, adding complexity and cost to their code. Because of the significant costs involved with the less-than-ideal replication, ongoing non-trivial capacity planning and adjustments are required, and if they result in additional application changes, the same inflexibilities mentioned add cost and impact developer productivity.

Unlike DynamoDB, Fauna allows developers to model and reason about their data access patterns, without prohibitive index duplication costs, data consistency and transactional compromises, and with minimal performance penalties. Users can organize their data in multiple ways, across collections or databases, and still be able to query deeply nested data in larger JSON documents (400kb max for DynamoDB vs 8MB max for Fauna). Data manipulation and calculations can run transactionally and users can leverage server-side user defined functions (UDFs), which work as stored procedures in traditional databases. Data access patterns and indexes can freely be changed over time to further optimize performance, without having to contend with partitioning details, expensive indexes, full table replicas, and enjoy the same transactionality either within or across regions. Less compromises and flexible changes can be used to control and reduce code complexity, making developers more efficient.

Caveats for developers when global tables are required in DynamoDB

Your application can read and write to any replica table, but if it requires strongly consistent reads, it must perform all its strongly consistent reads and writes against the same region. Any newly written item is propagated to all replica tables within a second — not an insignificant latency — and that ACID guarantees only apply within the AWS Region where the write was originally made. It is up to the developer to apply custom business logic to determine when to redirect requests to other regions and make their apps resilient to regional outages. Dev productivity and code complexity is affected,while still handling eventual consistency and non-transactional side effects.

When using indexes for query access options in DynamoDB, both database and developer costs increase significantly

It is up to developers to judiciously use expensive indexes when additional required access patterns require it. If any additional computation or manipulation of data is required, it must be handled by burying additional data in near key-value subsets that cannot be readily accessed or indexed, or store the data in a different place, or shift additional logic in application code, or a combination of those options. The same eventual consistency and non-transactional side effects need to be addressed and maintained in developer code.

Fauna has less data, item, key, value, and size limitations

• Fauna allows for JSON documents up to 8MB in size, vs 400kb for item (record) size in DynamoDB
• The size of data will impact the size of indexes, which are larger and significantly more expensive in DynamoDB

Faster index creation:

• In Fauna, indexes combine the concepts of indexing and materialized views in databases; ordered data can be accessed in the index directly. The cost of indexes is marginal and much smaller when compared to DynamoDB
• The cost and performance of indexes in Fauna are low and consistent even when considering both global secondary indexes and global table equivalents

Fauna's higher request throughput allows the DB to do more of the work vs your application

• Because indexes can handle multiple terms, and functions can further compute and manipulate data in sets, transactional queries that handle more data elements are possible, minimizing the amount of requests required. It makes application developer code more concise, flexible, and easier to maintain.
• Using user-defined functions allows for processing to happen at server-side speeds with the same strong consistency and transaction guarantees, something that it is not possible in either single-region or global table use cases in DynamoDB. High transaction guarantees also result in developers not having to add logic to handle eventual consistency side-effects.