Fauna CEO says cloud APIs help developers build apps without a database

Advances in distributed, serverless computing have changed how databases are used in modern application development. For its part, startup Fauna set out to make database development more developer friendly with cloud APIs.

Fauna is not a database in the traditional sense. The company’s web site calls Fauna a “data API for modern applications.” VentureBeat sat down with Eric Berg, Fauna’s CEO, to understand what motivates the startup and what the company is doing differently.

This interview has been edited for brevity and clarity.

VentureBeat: So why did you end up building Fauna?

Eric Berg: I think what I’ll start with is the genesis of the company, which kind of explains what’s been built. The founding technical team came out of Twitter. They had started when Twitter was small and then went through all the pains of scaling the infrastructure. Evan Weaver, who’s our CTO, ran the data infrastructure team. He tried to use every tool out there at the time, which was when a plethora of NoSQL options arose. So they tried Memcache, Redis, Cassandra and so on.

They got frustrated with the fact that there wasn’t a good single solution and said: Why shouldn’t there be a very easy way for a team to start small on an application. Then, with an incredible developer experience, be able to seamlessly scale that service without having to become an expert on caching, denormalization, replication, and other architectural issues of the backend. All the things, the sort-of baggage that goes with traditional databases as you scale, right?

VentureBeat: So you want to build something simple to use?

Berg: Yes, we’ve taken [the traditional database] up even a higher level of abstraction. With Fauna, you don’t know and don’t have to know about the physicality of your database at all. It literally is delivered as an API much like Twilio’s API or Stripe’s payments API. You don’t have to pick a machine and memory etc. You just create a database. We take care of all the replication and the scaling and everything that needs to happen on the back end.

VentureBeat: So what kind of use cases are they tackling?

Berg: We’ve got a set of users who come to us from a more traditional relational database background. They come from an understanding of something like PostgreSQL or MySQL. They really love the fact that we combine that relational capability, that consistency and transaction support with basically no database operations. That’s very compelling.

Then we have a set of users who are really rethinking their application architecture. They tend to be more front-end developers and they don’t have a database background. And so for them GraphQL is a very natural interface to Fauna. So that’s a very easy way for them to get started.
As you go forward and you really want to tap into a lot of the underlying power of Fauna, you tend to see people then progress into using some combination of GraphQL and our FQL [query] language.

VentureBeat: So, developers are using it for any use case that needs to store data, right?

Berg: Yes. They’re attracted to the operational flexibility. And the fact that they don’t have to know anything about caching, normalization, replication, architectural rewrites, or anything associated with them. Or anything associated with having to scale and manage a database. That’s huge.

Number two, the fact that it is an API, so it’s directly accessible over HTTP. So, you don’t have to have any connection pooling or any kind of overhead associated with connecting to and interfacing with the database. You can directly address the database from a web browser or from a mobile application.

VentureBeat: And it’s not just the hardware support, right? You’ve also opened up the data structures to be simpler while giving Fauna the power to reason them?

Berg: Fauna has a very flexible set of data models. We support both relational and document models for querying data. Then we have this temporal component that allows us to really sort of play [the data] back and forth. We also have very strong consistency guarantees, which you would traditionally associate with a relational database.

Oftentimes I’ll tell people that we’re trying to combine the promise that developers loved about traditional Oracle or PostgreSQL or MySQL with the developer flexibility of something like a NoSQL document database. Then we’ve removed that operational complexity so that you can scale very easily.

VentureBeat: And the developer approaches it as a basic cloud API?

Berg: Yes! You can get started in a more standard interface so we support GraphQL, which is very popular these days.Then we also support a concept that’s very similar to stored procedures that you’re probably familiar with in the SQL world. We have what we call UDFs or , “user defined functions”. We have a language called FQL for that. That’s a very powerful language that allows you to basically capture your business logic [and embed it] in a Fauna database.

VentureBeat: This isn’t complex to use, at least if you’re dealing with all of the HTTP AJAX calls that are so common now.

Berg: Absolutely. It’s directly accessible over HTTP. You don’t have to have any connection pooling. [There’s not] any kind of overhead associated with connecting to and interfacing with the database. [That’s big] especially for those front end developers, right? You can directly address the database from a web browser or from a mobile application. That’s very compelling.

VentureBeat: This turns the db from a backend tool into something that doesn’t need the other tiers. It talks directly to the user’s machine.

Berg: SQL is King in the OLAP/Data Warehouse world. Developers, not many of them really love it, and it takes work [with all] of the ORMs (object-relational mappings). So we’ve tried to come up with a much more developer friendly and native experience that you can tap into from the language of your choice.

VentureBeat: But then what does the developer do about security?

Berg: We have a pretty powerful security model in our authorization framework. It’s an attribute-based access control layer that is native to the database. In addition, for customers that want to use a third-party authentication solution we have standards-based integration with identity vendors like Auth0. From an identity perspective we give people that flexibility. If you want to build your own layer, you can. Or if you want to tap into an off-the-shelf layer, you can.

VentureBeat: Are there trade-offs?

Berg: People might say, well, this is not much different from a serverless database like DynamoDB. But DynamoDB has a much less flexible developer and data modeling experience and you’re not getting the transactionality in those services. DynamoDB evolved from Amazon.com’s need to solve the sort of shopping cart problem at scale. And so it’s a very simple but extremely fast key-value store that does just that. It started out to do that quickly and does that very, very well. But it doesn’t offer the same consistency or developer and data model flexibility.

People might compare us to something like DynamoDB, because we are both serverless, and say, “well, Fauna, you know, you’re not sub-five or ten milliseconds for your latency,” Why is that? Well, if you want global consistency, then that’s going to take on the order of 100 milliseconds. And if you try to run Dynamo in their mode which attempts to deliver transactional consistency you will see similar latency tradeoffs.

VentureBeat: And this is a big part of what the developers need. It’s another worry you take off their shoulders.

Berg: Evan Weaver, has written some great and very detailed blog posts to really help people understand how Fauna’s architecture compares to other serverless databases like DynamoDB or AWS Aurora Serverless. Those posts do a great job of comparing and contrasting the developer experience and the underlying architectural approach, which is important for people to understand when they are considering the impact of those architectural trade-offs.

If you’re looking for the absolute lowest latency of, say, sub five milliseconds, our architecture is not that. That’s not what we’ve optimized for.

We offer a combination of very good performance, a seamless, no-operations required developer experience, and a commitment to transactions. When people are building business critical applications where the consistency of that data is really important that tends to be a really good fit for Fauna. And many customers are really attracted to the fact that Fauna means they have zero operational overhead for their database.

VentureBeat: I noticed that the company’s name doesn’t have the letters “DB” in it. It’s just “Fauna”.

Berg: Yes. There are really two things driving that. One is that we are, as we discussed, delivered as an API. Removing the DB helped better communicate the fact that our delivery model is fundamentally different. Also when you look at Fauna it is a unique combination of a powerful storage engine and a programmable compute layer that is globally distributed.

Over time the architecture will allow us to expand Fauna’s offerings. Keeping DB just felt like it was a little bit more limiting. And so we went to a broader term “Fauna.”

Source