Fauna: The Truly Serverless Database
Executive Summary
In a serverless platform, databases differ from applications as they must retain state.
A 'truly serverless' database is fully automated, abstracting all deployment, infrastructure, and vendor-specific considerations - with no upfront or ongoing intervention. It should simply 'just work'.
Managed and hosted databases are not truly serverless, as they rely on provisioned, dedicated implementations and legacy technologies. This approach introduces challenges with scaling, performance, cost efficiency, consistency and often requires provider-specific configurations.
Achieving true serverless requires a new approach. Fauna delivers this through these key serverless elements:
- Connectivity scale. Via a stateless HTTP API.
- Operational scale. Seamless scale to zero/peak and the ability to grow over time via distributed multi-tenant clusters.
- Data accuracy. Strong consistency & ACID transactions.
- Performance. High concurrency, while maintaining low latency, via a novel Calvin-based engine.
- Resilience. Multi-location clusters spanning zones, regions or clouds.
- Geographically distributed. Low networking latency via a smart load balancer routing between multi-active replicas.
- Optimize costs. Via shared infrastructure.
With Fauna, applications can interact with a truly serverless database that fully abstracts away any considerations for scale, performance, availability or data accuracy.
Introduction
To be truly serverless, a service must completely abstract away any level of consideration for what, where and how the service is running. Further, a serverless service should behave predictably regardless of scale and be billed purely by consumption.
While this type of service has been available for business functions for a while, it has yet to be delivered for a database. This inequity caused a number of issues for those attempting to adopt a fully serverless platform including:
- Inefficient costs
- Scaling issues
- Capacity planning
- Inconsistent performance
- Vendor specific configurations
The Challenge for Serverless Databases
Thus far, serverless has mostly lived in the execution tier. Containerized apps, edge workloads and lambda functions have exploded in usage but databases are still a dedicated, provisioned layer in platforms. Why? Because business functions are isolated and ephemeral; they do not maintain state. Conversely, a database’s value to a platform is to store data and accurately maintain its value over time and between access points. Databases have to consider:
- Data is persistent. It cannot disappear and then reappear as needed.
- Data has a location. It is either in one place or must be maintained over multiple places.
- Concurrency controls between multiple consumers.
- Alignment of multiple resources for both software (compute and memory) as well as hardware (storage).
It is the physical nature of data and state that make ephemeral processing so hard to achieve for databases.
Hosted & Managed is not Serverless
As traditional database vendors have attempted to align their offerings to the modern and cloud-optimized serverless design patterns, many have begun to offer hosted and managed services. However, these fall short of being truly serverless in that they are still dedicated, provisioned versions of their legacy technology. With dedicated resources comes the common issues with scaling, performance and cost efficiencies.
How Fauna Built a Truly Serverless Database
Fauna was founded in 2016 with a mission to redefine the traditional database experience that plagued application developers. Rapid development, simplified change and effortless scale should be fundamental to a database’s design, not encumbrances, and only a truly serverless database could accomplish this. For an entirely new experience Fauna implemented an entirely new architecture, transactional engine and deployment model.
To better understand what Fauna has created and how it accomplishes a truly serverless experience, let’s break down what exactly 'serverless' means. For a database to reach a state of true serverless, it must address three key aspects:
- Deployment awareness: A truly serverless database is both immediately available and requires no user-facing installation, configuration or maintenance.
- Infrastructure awareness: A truly serverless database completely abstracts away the underlying location and hardware allowing predictable, reliable performance at any scale from any location.
- Vendor awareness: A truly serverless database requires no specialized or unique configurations or considerations that would affect usage patterns, data accuracy, resilience, performance or costs.
These traits ensure that the database operates seamlessly without intervention, maintaining efficiency, agility, and scalability at every level as well as fully abstracts vendor implementation details that would otherwise influence data modeling and/or access patterns. In short, a truly serverless database will operate as a purely abstracted data storage service where any data gathering or storing event can be executed at any time and will execute with predictable latency.
Deployment Awareness
The first trait of a 'true serverless' service is fully supporting all of the elements that go into provisioning, deploying, installing, configuring, and updating a service. This removes the manual effort and skill sets required to deploy a service. However, deployment automation does not abstract away the knowledge or implications of the underlying hardware.
It should be noted that while 'managed' and 'hosted' offerings automate the deployment considerations, they are commonly still single use-case/tenant deployments where dedicated resources are behind each provisioned service. Dedicated hardware causes a range of challenges from potential cold starts, to reactive auto-scaling (move to larger hardware), to static billing (billing for what has been deployed, not what was used), etc.
How Fauna Eliminates Deployment Awareness
Fauna goes a step behind deployment automation and offers multi-tenant platforms that are already provisioned and operating. This allows for several advantages:
- Immediate availability. Whether deploying the first database or allocating additional tenants yourself (as child databases) the allocation of a database is a logical allocation and is immediate (automate rollouts or multi-tenancy, etc.).
- Simplified allocation. All that is required for a new database is its name. No additional pre-configurations are required and each database equally lives in every location’s multi-active replicas.
Infrastructure Awareness
The next trait in offering a truly serverless database is to completely abstract all considerations of the underlying infrastructure. While the first trait (deployment) is about abstracting the management of resources, this trait (infrastructure) is about abstracting the sizing of resources and any effects this could cause. A truly serverless database should reliably operate without any prior or ongoing coordination of resources.
To fully remove infrastructure awareness a database platform needs to support the following items with architecture, not coordination:
- Scale of connectivity, concurrency & storage
- High availability & resilience
- Consistent performance (at all times and at any scale)
- Geographically distributed users (being serverless means localizing network latencies)
- Billing for consumption, not allocation
Without an architecture built to be serverless-first a number of challenges can arise. Performance can degrade due to congestion of allocated resources, delayed scaling events or for geographically distributed users. Costs are inefficiently aligned to allocations instead of consumption. Effort, time and specialized skillsets are needed to manage allocation configurations. In short, infrastructure awareness takes away application focus while delivering a less optimal usage and cost profile.
How Fauna Eliminates Infrastructure Awareness
Completely abstracting away infrastructure is a difficult challenge for services that must always be available and durably maintain state. An entirely new level of service takes an entirely new approach. Starting from the ground up, and with cloud-first techniques, Fauna built a database as a platform with the following core elements:
- Multi-tenant platform. Only through a shared, multi-tenant service could a service be always available, allow scale to zero, to peak and over time as well as pass along the cost savings of shared infrastructure.
- Multi-region, multi-active replicas. To remove networking latencies from an increasingly geographically distributed user base as well as increase overall reliability only distributing replicas over multiple regions would work.
- Strongly consistent. Maintaining strongly consistent transactions over multiple regions required an entirely new coordination engine. Fauna implemented an optimized version of the Calvin protocol that vastly reduces the coordination involved in synchronizing commits and allows for low latency over high concurrency.
- Scalable connectivity. Fauna aligns database and application connectivity by exposing its service via a REST API using HTTPS and bearer token authentication.
- Intelligent routing. To remove locality and availability considerations Fauna’s endpoint is an intelligent load balancer that handles routing to the nearest multi-active replica.
- Distributed storage. Evenly distributing data over all storage nodes per replica allows for storage and access scale without limits.
With a core of a multi-tenant cluster, Fauna is able to provide on-demand utilization without maintaining dedicated resources or passing along their costs. By spreading that out over multiple regions, along with an intelligent load balancer, allows for high availability and geographic performance. Using the Calvin protocol allows for ultra fast performance and strong consistency. These all combine to create a service where it is always available, always accurate and requires the least amount of hardware.
Serverless Should Cost Less
Truly serverless systems share resources instead of dedicating them *. This allows for the underlying hardware to already be provisioned when needed and allocated elsewhere when not. It also allows for fine grained billing, amounting purely to usage, instead of in chunky allocations.
Multi-tenant architectures are the key to scale, performance and cost effectiveness.
- In some cases isolated or dedicated infrastructure is required for security, regulatory, or use case specifications; Fauna offers a customized, dedicated deployment model, Virtual Private Fauna - which allows customers to tailor an otherwise fully serverless Fauna deployment to specific isolation, security, geo-location, & hosting requirements.
Vendor Awareness
In the previous sections, we focused on the external deployment and infrastructure aspects of a serverless service. Now, we'll look inside the service to understand how database feature implementation can impact applications.
For business functions the choice of resource vendors items like CPU, memory, or networking is typically irrelevant. However, for databases, vendor-specific features—like consistency, transactional integrity, and data modeling—are critical to data handling, access patterns, and reliability. Although serverless aims to abstract operations, understanding database features implementations remains essential for effective application development. True serverless databases should support strong data consistency, seamless change management, and flexible modeling options without requiring vendor-specific adaptations.
How Fauna Eliminates Vendor Awareness
Fauna pushes full serverless into the database by eliminating provider-dependent limitations and nuances. This allows builders to focus entirely on their applications. To ensure seamless interactions and production deployability, Fauna delivered the following:
- Always strongly consistent. As a byproduct of the Calvin-inspired transaction engine, all changes are strongly consistent. This includes ACID compliance of multiple statements in a transaction, synchronized changes over all multi-active replicas (locations) and read-your-write capabilities. This goes for every operation, every time.
- Document + Relational. Let your data and access patterns model the data, not database limitations. Fauna’s document-relational model stores data as JSON documents, allowing interactions to be application-native (in the same shape as application code), but also offers native relational capabilities such as query joins, schema enforcement and server-side functions. Supporting both document and relational modeling patterns unlocks the best of both worlds for builders.
- ORM-like language. To remove the need to also learn a SQL dialect to work with data as well as remove the need for an ORM or middleware, Fauna’s operational language, FQL, is Typescript-based and modeled after an ORM. Developers can fluently operate on data without switching mindsets or learning full new languages.
- Online schema & change management. Fauna fully supports Agile development methods and practices. Application development is iterative and the shape of data will change over time. Fauna makes change easy by:
- Enabling schema changes online. From collection definitions to indexing rebuilds, all operations occur while the database is active;
- Deploy all changes together. To align with application code roll-outs, Fauna allows for many schema changes to be implemented at once (like many new or changing indexes) as well as alignment of database changes to application deployments.
- Support changing schemas without re-writing data. Often, when a schema changes, the existing data must be modified to comply. This takes time to implement, requires coordination, makes roll-backs difficult and can add to costs (when charged per operation). Fauna uses migration blocks to logically apply changes on-read. This allows for immediate implementation, no data manipulation and self-documenting of what and when things changed.
With these combined feature sets an application developer can rapidly build new features, interact with their data as if it were truly another service, and can deploy database changes together with application feature deployments. This extends the abstraction one layer deeper by eliminating the most tedious and application influencing effects of database implementations.
Serverless Resources
Resources to get started building with Fauna
Fauna starter tutorial 'Debunking Serverless Myths' webinar Fauna & AWS serverless workshop Fauna & Cloudflare serverless workshop Schedule a demoConclusion
Achieving a truly serverless database requires overcoming the challenges of deployment, infrastructure, and vendor dependencies. Fauna delivers this with an innovative, serverless-first architecture that redefines how databases operate. By abstracting deployment and infrastructure considerations, eliminating vendor-specific limitations, and ensuring strong consistency, Fauna empowers developers to focus solely on building and scaling applications without the burdens of traditional database management.
Fauna’s multi-tenant, globally distributed design, coupled with a Calvin-inspired transactional engine, ensures high availability, low latency, and seamless scalability. Its document-relational data model, online schema changes, and application-native interactions makes it a powerful, flexible solution for modern development needs. Fauna not only simplifies the database experience but also aligns it with the true principles of serverless—delivering efficiency, agility, and cost-effectiveness for today’s applications.
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.