Let's talk about FaunaDB!
FaunaDB, also known as Fauna database, or simply Fauna, is a relatively new kind of a cloud database. It is server-less and distributed, has native support for a document-relational data model, and is packaged as a developer-friendly cloud API.
Lot to unpack there, and we'll get to it in a moment, but FaunaDB has an interesting premise that we should first discuss!
Most developers, especially the ones building modern user-facing mobile applications, would rather focus on application concerns than deal with cumbersome administrative tasks, such as database provisioning, upgrades, replication, and scaling. This makes sense because developers want to spend time doing things they're good at, and which will advance their company's business outcomes.
Secondly, modern applications typically use API endpoints when interacting with external services, such as payments processing, location services, and engagement tracking. And yet, when it comes to database accesses, developers are required to use either a SQL dialect, or some kind of an ORM (an Object Relational Mapper), in order to access and process data stored in the database.
This traditional-style interface creates a strong binding between the application and the database. A clean micro-service architecture, on the other hand, requires the persistence layer (the database) to be strongly decoupled from the application. The impedance mismatch between the access patterns for the database, and for most other external services, causes friction for developers, distracts them, and slows them down.
FaunaDB aims to address these friction points in the developer experience, simplify data management, and accelerate development of user-facing applications in the process.
How does FaunaDB do it?
Fauna is a distributed serverless database. Serverless simply means that it's a managed service, similar to AWS RDS, AWS Aurora, MongoDB Atlas, and others. Since it's managed, cumbersome administrative tasks such as provisioing virtual machines, upgrading software versions, and backups are all offloaded away from the users (developers for the sake of our discussion).
Additionally, the service is globally distributed, which means user data is automatically replicated across multiple regions of the cloud. That provides redundancy in the event of of failures, and makes it easy to both scale the database and make it highly available, which is great news for developers!
Secondly, FaunaDB is a document database similar to MongoDB. Documents are inherently schema-less, which depending on the nature of the application, may be a good thing, as it helps the application evolve more organically to accommodate newer business use cases over time compared to a rigid relational schema.
Unlike MongoDB, though, Fauna also supports the traditional relational concepts of primary and foreign keys. This is in order to accommodate data models that require cross-linking related datasets (called
collections in FaunaDB) to build a unified view of the data.
Lastly, Fauna database has native support for the popular GraphQL query language. This is in addition to its own SQL dialect called FQL (Fauna Query Language). In recent times, GraphQL has been well adopted for a number of user-facing applications, as it decouples the core business logic in the application from the persistence layer (the database).
From the application's perspective, database accesses no longer require specific SQL dialects, or even ORM implementations, to be used. Rather, the application makes data access requests in a database-agnostic manner. A GraphQL server, running separately from the application, translates GraphQL queries into database queries, and returns the exact schema and data as the application requested.
Together, the serverless nature of FaunaDB, its document-relational data model, and its native support for GraphQL make it very appealing for developers of modern micro-services based applications!
So who should consider using FaunaDB?
I don't believe Fauna database would be a direct replacement for highly operational and production-focussed databases like MySQL, PostgreSQL, Oracle, and SQL*Server, where low latencies (sub-millisecond) and high throughputs (10s or 100s of thousands of Queries per Second) are a critical requirement.
Fauna database also isn't meant to be a replacement for analytics databases, such as Snowflake, Redshift, or Athena.
I believe FaunaDB will be an interesting choice for scenarios where the following conditions hold true:
- Ease of application development and database management trumps any needs for super-high performance.
- A clean modern application architecture with strong decoupling among the services, and between the services and databases, is desirable.
For both new applications, as well as those that are being migrated over from a legacy environment, as part of what's called "Stack Modernization", a service like FaunaDB will allow for fast prototyping, implementation, and ease of maintenance for developer-centric teams.
Fauna also provides tools for data migration, and is SOC 2 compliant, to make it easier for organizations to give it a serious thought for their projects!
One last thought!
In terms of the competitive landscape, if you're already firmly entrenched within either of the AWS or the GCP environments, you might want to consider AWS DynamoDB, or Google Firebase, as alternatives to Fauna database. Both are similar to FaunaDB in that they offload tedious data administration tasks from developers, and give them a more modern data access experience.
AWS DynamoDB and Google Firebase also have the additional advantage of natively plugging into the IAM subsystems of the respective clouds. Thus, applications will benefit from a more native and organic support for their authentication, authorization, monitoring, logging, and auditing needs!
Hope you enjoyed reading this!
Subscribe to my Data Management Newsletter for more original content on databases, data management and data protection!