Fauna is rethinking the database
This week weâre talking with Evan Weaver about Fauna â the database for a new generation of applications. Fauna is a transactional database delivered as a secure and scalable cloud API with native GraphQL. Itâs the first implementation of its kind based on the Calvin paper as opposed to Spanner. We cover Evanâs history leading up to Fauna, deep details on the Calvin algorithm, the CAP theorem for databases, what it means for Fauna to be temporal native, applications well suited for Fauna, and whatâs to come in the near future.
Matched from the episode's transcript đ
Evan Weaver: Not everybody. Obviously, a lot of Faunaâs features were inspired by things that we wanted to have at Twitter, and weâre forced to develop and forgo on our own. Fauna is really design for the modern web 2.0+ application world. With SaaS, in particular - I would say the majority of our customers are building some kind of SaaS app, with a business purpose. Or consumer-oriented applications. And then I think that the third category, which somewhat overlaps with the first, or blockchain-adjacent applications, things that use crypto for public transactional purposes, but also store additional data for application purposes.
The thing that these all have in common is that â you know, thereâs a wide variety of customers and people interacting with datasets that interact with it in a soft, real-time way; they interact with it from the web, from mobile applications⌠You know, itâs all the apps you use today.
What we donât do is analytics. Weâre not a olap database, weâre not a data warehouse. Weâre not a cache for some other database. The transactional consistency does have a cost in throughput and latency, so if all you want is a cache, you should go get memcache or something like that. Weâre not an information retrieval system; we donât replace Elasticsearch. Weâre not a queue. You can go get Kafka or something else like that for those purposes. Itâs really sort of the dream of MySQL, like - we wanna be to the serverless era, and JAMstack, and kind of the API infrastructure era the same way MySQL was to the web 1.0 era, where this is a general-purpose operational data platform. Itâs very easy to use, itâs very easy to adopt⌠No startup costs, develop on your laptop. It does a very good job; I mean, we can argue about whether MySQL did a good job, but it was a better job than others at the time, because it existed. It does a very good job at that core, short request transactional user data, mission-critical data, constrained indexed use cases⌠And then it does a decent job at everything else you need to build a fully-featured application, so that you can get started without having to have a whole bunch of tools all mixed up in your tool chain.
We fundamentally donât really believe in the classic polyglot persistence attitude where you pick the best tool for every single kind of query pattern you might have in your app. Databases are heavy pieces of infrastructure. Itâs hard to move data around. You donât wanna have too many of them. So the more general-purpose that it can be, the less you have to use. We do have an advantage in the cloud though, that we can connect and integrate more easily with adjacent systems in a way that takes the integration burden off the user. So thatâs one of the things weâre working on going forward, making it seamless to link up to the analytics database you wanna use, the queue you wanna use, and that kind of thing.