Why Fauna: The limitations of alternative databases and the Fauna advantage

In today’s digital landscape, every enterprise wants to be faster and more efficient, but development teams are frequently blocked by limitations of the database that underpins their application. Modern databases promise high performance, scalability, and ease of use but often fail to deliver in practice. Developers are forced to make significant compromises across a number of dimensions:

Developer experience in alternative databases

• SQL databases lack observability, do not support composability, and do not provide fine-grained control over the shape of data that is returned. They come with a query optimizer that is useful for analytical querying, but provides less value for transactional use cases and makes debugging performance issues extremely difficult. Features take longer to build and Mean Time To Repair (MTTR) is much higher for specific classes of production issues.
• The rigid, tabular nature of schemas in tabular relational databases creates friction with the object orientation of application stacks and does not fit with real-world situations where schema is not well-understood up front. Unstructured or semi-structured data needs to be shoehorned into columns, which blocks new features that require non-trivial queries over that data.
• Data access is handled via session-based protocols that leverage long-lived transactions and require connection management. Applications cannot be deployed to modern serverless environments with ephemeral compute, removing the ability to rightsize fleets and save on cost.
• NoSQL/document databases are missing important functionalities such as triggers, stored procedures, and views. These features need to be built into the application layer, which takes a lot of time and results in managing an unwieldy codebase.

Performance and correctness in alternative databases

• SQL query performance is highly variable and onerous to debug, particularly at scale. Features work fine initially but grind to a halt under load and create a negative customer experience.
• The object-relational mapping (ORM) abstraction on top of SQL hides capabilities of the underlying database and makes query optimization impossible. Engineers move more slowly because they can’t leverage powerful database features, and applications are less performant.
• Distributed databases require complex configuration for sharding, cross-region data replication, data locality (for data privacy and GDPR), and consistency levels. Enterprises need to staff the modern equivalent of database administrators (DBAs) that cost money and gate features.
• NoSQL/document databasess lack support for ACID transactions, forcing developers to handle edge cases (particularly for multi-document transactions) in application code. Unforeseen edge cases result in broken customer experiences, and custom transaction logic is hard to reason about and burdensome to maintain.

Scalability in alternative databases

• Alternative SQL databases scale vertically, which creates a mismatch with applications that scale horizontally. Applications work until they get broad adoption and tip over, requiring a battlefield rip and replace onto a more scalable solution.
• Modern NoSQL and distributed SQL databases require complex configuration to scale out, and capacity prediction is difficult. Enterprises lack the ability to right size fleets and either underspend and create performance problems, or overspend and waste money to ensure that they have enough capacity.

Operations in alternative databases

• Databases across all categories require varying levels of maintenance including machine provisioning, patching, vulnerability management, monitoring, and incident response. Engineering teams are stuck doing an immense amount of undifferentiated heavy lifting and only a small percentage of firepower is allocated for new features that move the needle for the business.
• Disaster recovery (DR) is complicated and error prone. DR plans sit untested and often fail when needed, resulting in catastrophic extended outages.

The pain is clear; use of these classes of operational databases results in application code that is harder to maintain, slower delivery of new features that move the needle for the business, poor application performance, long production outages, higher infrastructure costs, and increased risk of disruption in business continuity. Enterprises can try to work around these issues and live with the pain, but they will eventually be outpaced by competitors that embrace new technologies to gain efficiency.

Fauna is an innovative operational database that was built from the ground up to excel in each of these categories:

Developer experience in Fauna

Fauna is a relational database with a document data model, bringing together the best of the flexibility of JSON documents with powerful relational database querying capabilities. It features the Fauna Query Language (FQL), a powerful language that was deeply inspired by TypeScript and can express arbitrarily complex logic as part of a transaction. Transactions are sent to the database using HTTPS, removing the need for sessions. Transaction code can also be stored as user-defined functions (UDFs) for reusability and consistency.

Performance and correctness in Fauna

Fauna leverages its distributed transaction engine (DTE) to provide consistent query performance under load. Fauna’s DTE is based on Calvin, with significant enhancements to enable serialized transactions across wide geographies with a predictable latency profile. Data can be retrieved quickly via global secondary indexes, which enhance query speed and enforce uniqueness constraints. This system avoids unnecessary data fetching and allows explicit control over query execution. Fauna’s optional static typing and type enforcement system provides a mechanism to guarantee referential integrity across relationships, eliminating a multitude of problematic correctness edge cases.

Scalability in Fauna

Fauna scales horizontally without requiring complex configuration and has been proven to work at scale under demanding real-world workloads. Under the hood, Fauna replicates data across zones or regions to both optimize latency and provide robust fallback mechanisms in the case of zonal or regional failures. It can be deployed globally, regionally, or to a single region, facilitating fast local reads and robust service continuity. This scalable design caters to the increasing demand for geographically distributed data access.

Operations in Fauna

Fauna is delivered as an API – the best possible version of serverless. It removes development teams from the burden of operating a complex service. This model removes the need to manage infrastructure changes, deploy database upgrades, or design sharding strategies, freeing up resources to focus on the core business instead of undifferentiated heavy lifting.

Conclusion

In the realm of operational databases, the challenges are manifold – from issues with developer experience and performance correctness to scalability and operational hurdles. Alternative database systems often fall short of customer requirements and result in massive pain and inefficiency.

At Fauna, we believe that developers shouldn’t have to reason around unknown future access patterns, distribution strategy, or consistency profile and that databases should be built to service applications (and not the other way around). In the second part of this series, Why Fauna: Use cases unlocked with Fauna, we will explore the modern use cases that Fauna’s unique set of features helps accelerate.

• User-centric apps that require consistency and data privacy
• Distributed real-time apps that need swift data access at the edge
• Stateful serverless apps that demand faultless state changes
• Secure multi-tenant apps that call for robust data isolation

*Ready to get started building with Fauna? Check out the Fauna Quick Start or get in touch with one of our experts if you have any questions.