The flexible, distributed-by-default alternative to DynamoDB
Fauna is a serverless document database that provides multi-region ACID transactions at scale out of the box. Model your complex data freely with the only NoSQL database that has the relational capabilities of an RDBMS.
Scale seamlessly and unlock powerful querying capabilities
Many organizations cannot predict the future requirements of their application, and end up being constrained by the lack of flexibility in DynamoDB. Break away from the inefficiencies of DynamoDB and achieve low-latency ACID compliance with Fauna.
Better global data distribution with less complexity and cost
Once DynamoDB applications grow, and access patterns evolve, distributing data with Global Tables adds significant cost and causes a loss of transactional consistency.
Fauna’s distributed-by-default design retains strong consistency levels in all single-region, multi-region, and global use cases. Fauna’s cost remains efficient, straightforward, and transparent while maintaining strictly serializable transactions.
Stop trying to fit your data models into single-table designs
As DynamoDB experts admit, fitting heterogeneous and denormalized data entities into the recommended single-table design patterns results in models and table layouts that read like machine code. This makes the addition of newly required data elements and access patterns complicated over time.
Fauna combines the flexibility and productivity of unstructured data with the power of relational database features such as foreign keys, views, joins, and server-side functions.
No more indexing and key-value size limitations
In DynamoDB, only 5 local secondary indexes are available at table creation time, and only up to 20 global secondary indexes, with a maximum item/record size of 400k.
Fauna allows for JSON documents up to 8MB in size, 20x larger than DynamoDB. In Fauna, flexible indexes can be added at any time, are more cost-efficient than their DynamoDB counterparts, and retain strong data consistency.
See what Fauna can do for your organization
Get in touch with our experts and start your migration journey today
Frustrated with the growing costs of your DynamoDB implementation while being throttled by its inherent design inflexibility?
Fauna avoids all of those compromises — even across global regions — with full transactional and relational power.
Get in touch with Fauna
Comparison of serverless databases
DynamoDB | Fauna | MongdoDB Atlas | Cockroach serverless | Firebase | PlanetScale | |
---|---|---|---|---|---|---|
Connect over HTTP | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
No cold starts | ✅ | ✅ | ❌ | ❌ | ✅ | ❌ |
Multi-region by default | ❌ | ✅ | ❌ | ✅ | ❌ | ❌ |
ACID compliant | ❌ | ✅ | ❌ | ✅ | ❌ | ✅ |
Document-relational model | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |
Recommended resources
Articles and guides to help you kickstart your migration journey
DynamoDB pain points: How to address them and exploring possible alternatives
Everything in software engineering is about tradeoffs. This article gives you a clear picture of the various limitations of DynamoDB and how Fauna alleviates those pain points.
Considerations when migrating from DynamoDB to Fauna
Migrating from DynamoDB to Fauna will help you realize significant short- and long-term benefits while preserving many of the values that had you consider a serverless distributed database in the first place.
The architect's guide to building scalable global applications
Understand how Fauna provides an inherently global, cloud-first approach to address global latency and data sovereignty challenges.
Migrating from DynamoDB to Fauna will help you realize significant short- and long-term benefits
With Fauna, you don't have to compromise the values that had you consider a serverless distributed database in the first place.
Flexibility of DynamoDB vs flexibility of Fauna
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'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.
- 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
Caveats for developers when global tables are required in DynamoDB
When using indexes for query access options in DynamoDB, both database and developer costs increase significantly
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
- 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.
Ready to get started?
Sign up or get in touch with one of our experts and discover why thousands of developers love Fauna.