Fauna === Tyson: ~Troutman. Yeah. Tr troutman. Troutman. Yeah.~[00:00:00] Paul: Hi there and welcome to Pod Rocket, a podcast brought to you by Log Rocket. ~Log Rocket helps software teams improve user experience with session replay, ever tracking and product analytics. Try it for free@logrocket.com today.~ My name is Paul and joined with us as Tyson Troutman, VP of Engineering over at Fauna. With experience drawn from his time in the gaming industry over at Riot Games to tech giants like AWS and Microsoft. Tyson has definitely been around the block before coming to push serverless database technology to the next level. Welcome to the podcast Tyson. ~Okay. Gotcha.~ Tyson: ~Put on your do your best, uh, German, you know, get really gural and~ Paul: ~Yeah. Yeah. Troutman. All right. Test, test, test.~ Tyson: ~test, test, test.~ Paul: ~All right.~ ~Hi there and welcome to Pod Rocket, the podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking and product analytics. Try it for free@logrocket.com today. My name is Paul and joined with us is Tyson Troutman. He's the VP of engineering over at Fauna.~ ~And in addition to being over at Microsoft, Right games and even aws. He's come to sort of help push the envelope on what we know as databases and databases as a service. Welcome to the podcast.~ Tyson: Thank you, Paul. Super excited to be here. Paul: ~So~ before we hop into the details ~about like some of the features you might offer and why developers might wanna reach for it~ really quickly, ~you know,~ if you search up ~Fauna,~ fauna,~ excuse me, what it is,~ people say, ~well,~ it's ~kind of~ Postgres, but it's also not, and I feel like we, we hop into this conversation about ~like,~ is it a S SQL or NoSQL database? So where does Fauna sit in that spectrum and why is it ~kind of~ like ambiguous from what people might see on initial Google search? Tyson: ~Yeah, I mean,~ it's a good question. I'd say, first of all, there are a lot of different dimensions you can think about when you're trying to ~kind of~ categorize the database market. ~You know, uh,~ apart from those dimensions, the way we like to think about Fauna is if you described all of the [00:01:00] attributes that you would want outta ~a,~ a modern transactional database. ~You know,~ we think Fauna really checks a lot of those boxes and is really ~kind of~ purpose built for, ~um,~ modern application development. ~You know,~ I guess more technically just to think across some of those dimensions. ~Um, so, uh,~ fauna stored the data model, ~uh, you know,~ fundamentally is. Documents, but fauna, ~uh,~ supports, ~uh,~ relationships across documents. It supports a lot of these kind of foundational relational concepts in the relational calculus. ~Um,~ so you can do things like joins, ~uh,~ across types to find in documents. ~Um,~ and there are also other ~sort of, uh,~ fundamental properties that people associate with relational databases like. Strong acid guarantees that, ~that~ that fauna,~ uh,~ also provides. So we've used the moniker document, relational in the past. You trying to convey, bring little bit of those, but you really, ~I, uh, you~ fundamentally, it is a different of database. Paul: I, I think that's a really cathartic answer to here is it's like a [00:02:00] fundamentally different type of database because it ~kind of~ hurts my brain to put it in one of those buckets when I'm trying, when I'm going through the feature list and there's a blog post that, ~uh,~ you guys have out, ~like~ modernizing from PostgreSQL into Fauna and ~like~ what that might look like. And there's a list about here's what's different, here's what's the same and. There's some things that are the same and there's some things that are different. So fundamentally, ~we're,~ we're talking about a different type of database and I really like that. ~Um, do you think that this, and,~ and you talked about how this sort of got born out of a need for like, we want to make sure we're having the right features such as asset compliance. ~Um, do you think that this vector of what you,~ you talked about the vectors of dimension of how we're looking at databases. Is this, what ~kind of like~ motivated you and the team to create fun of ~sort of,~ we want this to be developer oriented versus ~like,~ Data model oriented for our vectors of creation. Tyson: ~Yeah, for sure. I mean, we, you know, when you're building a database, uh,~ I think it can be a little bit easy to get off than like ~the,~ the technical, ~you know,~ there's a lot, you're solving problems ~kind of~ on the cutting edge of distributed systems, but none of that really matters at all if you're not solving real problems that developers have. So we very much try to ground. What we're building in, ~uh, you know,~ how it makes life better for developers. FAO was actually [00:03:00] born, the two co-founders, ~um,~ Evan Weaver and Matt Fris, ~uh,~ were ~uh,~ technical leaders at Twitter in the early days, and they saw this kinda need for a new transactional database and they set out to build ~sort of the,~ the thing that they wanted at Twitter. ~Um,~ and then ~we're heavily kind of~ stumbled upon this Calvin Research paper that came out of Yale written by, ~uh,~ Daniel Body as upon advisor and some other folks. That was an interesting spin on how to do distributed consensus. ~Um,~ and like we were saying, ~kind of~ could tie that back to these interesting properties, you know, that really made life better for developers and that was kinda ~the,~ the genesis of Fauna. Paul: Now you mentioned a transactional database, Tyson, could you tell us. Us a little bit about what that means, why it's important, and maybe is there like an example of something out there that people reach for on a daily basis that at its core is not transactional, where that might not be at the forefront of your concerns, just so we can have an example to compare against. Tyson: ~yeah, for sure. I mean,~ so the typical kind of highest level way to segment the database market is you have, ~uh,~ transactional databases or O L T P databases and [00:04:00] analytical ~debate, uh,~ databases or OAP databases. ~Um,~ it's not binary. ~It's kind of,~ there's ~kind of a,~ a blurry line between the two, and you can, ~uh, you know,~ a lot of databases will support ~sort of, uh,~ analytical, ~uh,~ workloads on top of a transactional database. So it's not like you hit this threshold and all of a sudden you move from one type to another cleanly. ~Um,~ but really the hallmarks of a transactional database are, ~um,~ a database that kind of. ~Uh,~ backs and application where that application is going to be doing frequent, ~uh,~ reads and writes to the database. ~Um,~ typically also there's a built in requirement there of kind of low latency. ~Um,~ so if you think about things like a customer metadata store, which is how a lot of customers use fauna today. ~Um,~ or even just things like tracking, ~uh,~ like a shopping cart across a session. ~You know,~ a lot of these things will happen using a transactional database, whereas an analytical database, ~you know,~ is something where, ~you know,~ typically you're gonna write a lot of data. ~Um,~ so potentially a lot of rights. They can be batched, latencies, less of a big deal. And then periodically you're gonna issue these analytical queries that are very expensive, ~you know,~ take a lot of [00:05:00] time to run and then show you a result at the end of that's, Paul: So you mentioned customer metadata is ~kind of~ like a common use case here. Why do you think that's settled naturally? With Fauna serving ~that,~ that, ~that Uhuh~ market so well. Tyson: ~Yeah, good question. I mean, I'd say, um, you know, so when,~ when I say customer metadata, what I mean is for all these different, ~um,~ applications, ~you know,~ you have a customer, the first thing they usually do is, ~uh,~ something like create an account. ~Um,~ and then you store this kind of data about the customer specifically. ~Um, it's not kind of~ the core data that you're supporting for the application. ~So, um, uh,~ I'll use the a video game example, cause that was a world I spent some time in. ~But you know,~ in the video game world, ~you know,~ you might have a database where you store player data, so things like entitlements, ~you know,~ and, ~uh,~ I'll use League of Legends as a game I worked on, but you might have purchased specifics, for example. ~Right. Um,~ That you can access in the game or in-game content. And that's all kinda player data. Metadata is more like, ~you know,~ the high level, ~um, sort of~ attributes associated with that. ~Um, uh,~ that specific person that created the account. I guess why that works. So [00:06:00] I think there are a few reasons. ~You know,~ the first is, ~um,~ that data, ~uh,~ is. ~Uh,~ a document formats are conducive to that data because you don't always want to enforce ~sort of~ rigid schema and all that data landing at a specific point in time. ~Um,~ you might wanna add ~sort of~ metadata as you go. ~Um,~ oftentimes you have relationships between metadata, ~so, uh,~ a player might have friends. And so this built in like first class support for relationships between entity types or documents, and is really powerful in this context. Another one is when you're storing data ~about, again, using the,~ sticking with this example, but about players. ~You know,~ you typically, ~if you're,~ if you're building a global application, you typically have things like, ~um, that you like~ compliance that you need to think about in terms of where that data actually resides. And Fauna has a really compelling model there where we replicate data across regions, but we do that within a specific geographic footprint. So if you need to make sure your European player data stays, ~Um,~ in specific EU countries for GDPR compliance. We have a great story there that really takes ~that,~ that [00:07:00] lift, ~um,~ outta the application ~and,~ and we handle heavy lifting. Paul: So it sounds like you're able to distribute data around the globe, and that's ~kind of~ like another hallmark about fauna. You can take your data and I don't have to think about it as a developer, I can just tell it to go somewhere, and it ends up there at if you don't tell it to go somewhere. Is Fauna also ~sort of like, uh,~ expressing these flavors of the edge services that are coming out where no matter what, the data's already replicated in several geographical locations? Tyson: Yeah. Yeah, absolutely. So one of the kind of, I think, foundational properties of fauna, ~um,~ is it is a, it is multi-region by default. So we replicate data across regions in what we call a region group. ~Um,~ and we do that with. The highest possible level of consistency guarantee. So we offer strict serializability for transactions, which basically means you don't have to think about these weird edge cases around consistency in your application, right? That can be very difficult ~to, to,~ to reason about. Very expensive, ~uh,~ to build at the application layer. And ~so, um, When you,~ [00:08:00] when you actually spin up a database in Fauna, you do that, ~um,~ within what we call a region group, which kind of defines the footprint where that data lives. So we have a few different public region groups, ~uh,~ in the us, in eu, ~um,~ and then we also have this concept of what we call virtual private phone or v vp where, you know, enterprise customers can come to us and say, We actually want this specific footprint across these cloud providers, and we want very strong isolation like VM level isolation while retaining that serverless abstraction. So we don't wanna manage the infrastructure, we wanna stay serverless, but we want strong isolation in a very customized footprint. We can do that as well. ~Um,~ so you define ~kind of~ which one of those region groups a database lives in? And then when you send us data, that data has a key. That transaction that you send us has a key associated with it. We've invested ~very,~ very deeply in our routing infrastructure, ~um,~ and basically have ~a,~ a really compelling story there for the way that request gets routed all the [00:09:00] way from the application, which could be running, ~you know,~ at the edge, and a client, an iot device. ~Um, uh,~ we will ingress at the closest pop or cdn, ~um,~ use optimized backbone from there to get to the closest node in that region group, ~um,~ which has some pretty, ~uh,~ performance implications as well. Paul: Anytime a developer wants. To interact with the database, whether it be for their front end or the backend, whatever, like the, there's always those hallmark, those blue chip databases you'll reach for like the Postgres Tyson: Mm-hmm. Paul: and the Mongo, and there's ~like~ so much documentation. ~Not that, I mean, if you go to~ the Fauna docs are incredible and they're like visually beautiful as well, so you should read those if you, if you wanna figure things out. But there's no denying, there's ~like~ the your blue chip databases and. ~If,~ if somebody were to come ~and,~ and want to build something with Fauna specifically ~there, it,~ it sounds like, ~uh,~ the team has put in a lot of energy, as you said, into your routing infrastructure, the way you distribute data around the globe. Would you almost argue that ~being a,~ being a customer, being a user of [00:10:00] Fauna, you're buying into an infrastructure ecosystem more than a database product? Tyson: ~Yeah, I mean, I really, you know, so~ maybe to step back just a little bit on that, like fundamentally what we wanna do is make it so that our customers can worry about. Their application and that's it, right? ~Like~ no one ever set out to build an app and said, Hey, ~you know,~ along the way I wanna solve all these hard database problems. I wanna think about managing stuff that's non-differentiated. ~You know,~ I wanna deal with all the concerns associated with that. ~You know,~ what we hear from, ~you know,~ universally from all of our customers is make me faster. Let me, you know, think about less, put less cognitive load on, ~uh,~ on our engineers so we can really go and innovate for the business. And so everything that we've done at Fauna is ~kind of~ in service of that. ~So if you think about, um, you know, to,~ to ~kind of~ connect that to the database market broadly, ~you know,~ there are a few of these different kinda dimensions that you can think about when evaluating database offerings. ~So,~ for example, are they single region or multi-region, right? Or are they. Consistent, or do they have some kind of an eventual consistency model? Are they serverless or do they require infrastructure [00:11:00] management? ~Right. Um, the, the,~ the interesting thing about those different dimensions is that depending on where a database falls on that spectrum, they can make your app, ~you know,~ more performance. ~Uh, you know,~ quicker to, ~uh,~ evolve to meet your customer needs. And that's really kind what, where we spend a lot of time thinking, ~you know,~ with, ~uh,~ relative to competitors and what features we prioritize. Paul: ~Uh, because~ it almost feels like sometimes when a new database comes out, ~like, uh, you know,~ duct DB for example, they're like, listen, we have this like whole new way of fundamentally like storing things and there are fundamental differences with fauna. ~Like, ~and we're talking about the document model and how you're building in all these relations and all that. ~Um,~ But the lion share of ~like the, uh,~ of features and why it'll speed up my application feels like it's in this ~like~ global, ~like~ monstrosity ~that you,~ that you guys have built. ~Uh,~ I don't, I, I don't wanna use that word cause it's a beautiful monstrosity, but ~uh, uh,~ in an amazing way to Tyson: the clarification. Paul: ~Uh,~ to ship and bring data around the world in a really quick way. ~Um, it's,~ it's almost less of ~like~ a how do we store data cuz we have so much space available to us and how do we ~like~ access the data?[00:12:00] Tyson: Yeah. Paul: pull it out. ~Um, I know,~ I know it's both ends of the spectrum, but. Tyson: No, ~you're making, I mean, ~you're making~ a,~ a great point, which is ~like,~ this is a very crowded space. There's a lot of different database products that are competing for attention. I think as a developer, it can be really hard to sift through, ~you know,~ where do I start? What matters in my application? ~Um, You know,~ and it's, to me, again, you have to start thinking about everything from the application requirements, right? ~So, uh,~ what kind of performance do I need? ~Uh, you know,~ what kind of, ~uh,~ consistency profile do I need, right? Is it important ~that,~ that my app not see stad data, right? Which in ~is,~ is critical in a lot of different contexts. ~Um,~ what is the developer experience that I want as I'm building this app to make sure I can move quickly? ~You know, and,~ and ~kind of~ outrun my competitors. How does that, ~you know,~ how does that relate to infrastructure? And ~um,~ so those are the things to think about. And then I think take that, ~you know,~ and try to cut through some of the noise in the space and just, ~you know, uh,~ apply in a somewhat principled way, the different offerings that are out there to try to make a decision. ~Um, we could, I don't know if it's interesting, we could talk about some of these more concretely, you know, uh, in terms of the ecosystem, but I dunno how deeply we wanna wanna go here. Up to, up to you.~ Paul: ~I mean, I, I I, maybe we could double click on one of the things that you guys were ta uh, you're tackling when it comes to the infrastructure. Less of the data storage on disk in, in, in more of the infrastructure and ecosystem. But before we hop into that, I just wanna remind our listeners that this podcast is brought to you by Log Rocket, um, and Log Rocket helps you solve all sorts of bugs with your front end and full stack application for with session replay, ever tracking and product analytics, you can surface issues with AI insights and solve.~ ~Bugs bring users back for retention stronger than ever. Try your log rocket for free@logrocket.com today. So~ Tyson, if we could double click on some of the things that you guys are offering in your ecosystem. One of them is logs. So Tyson: Mm-hmm. Paul: the [00:13:00] way that serverless products ship store. And managed logs is different for, ~you know,~ EV every backend or SAS that you might interact with. What makes pH log special? Why do you think that it helps empower teams beyond what some other database or serverless databases might offer? Tyson: Yeah, ~I mean,~ so first off, A lot of, ~uh,~ our competitors in the serverless space or other offerings that are out there in the serverless space, ~you know, don't you know what,~ what they offer in their serverless offering specifically is very limited if you go look at it. ~Right? Like,~ and then part that's partially because lot of these products are coming from an on-prem world, trying to build some orchestration around something that was an on-prem product, and then make that serverless, which is a fundamentally different approach than what we're doing at Fauna. ~We,~ we set out to build. This database really, ~you know,~ from the ground up to be cloud native, to be serverless. ~Um, so, you know,~ I think what you see out there in quote serverless database in a very whitewashed term, I think used a lot different is, ~you know,~ varying degrees of support when it comes not just to logs, but observability [00:14:00] in general. ~Um,~ fauna Logs, which is a feature we shipped recently. ~You know,~ we, ~um,~ we followed kinda a principle that we have. We have ~kind of our,~ our core principles at Fauna. One of them is solve for the customer. That's kinda number one, ~maybe a bit of a page outta the Amazon playbook there. But, um,~ and so what we try to do early on in, in our future life cycle lot of times is launch something that. Unlocks customer value, customers can start using that thing. And then we can evolve that feature based on, ~uh,~ customer input. So we're not just building in a vacuum, we're really building what our customers are telling us that they need. And so with logs, what we've launched, ~uh,~ today is, ~um,~ the ability to go in and mint these account keys on your account that you can use to access these different control plane APIs for things like. Logs, backup and restore other functionality coming down the road. And, ~um,~ so at any point in time you can get in and, ~you know,~ either, ~uh,~ manually, like using our CLI or other tools that are out there, just sending an HTP request. You can download a slice of your query logs ~for,~ for, ~uh, um,~ a specific time window or, ~um,~ we have some documentation out [00:15:00] there that lets you wire this up to your observability tool. ~So if you use Datadog, ~You know, if you're, if you're running an elk stack, I think there are different options here for like, where you're ingesting those logs into. And part of that's cuz we don't wanna go in and like reimplement, ~uh,~ an observability tool. ~And there are plenty of players in that space.~ It's a very hard problem to solve. And so what we've prioritized instead is building flexible ways to get that data and then pipe it into the tools for you where you won't consume it. Paul: I just wanna remind our listeners that this podcast is brought to you by Log Rocket, Log Rocket helps software teams improve user experience with session replay, ever tracking and product analytics try your log rocket for free@logrocket.com today. I mean, that should be a hallmark of. Like a team that really knows what they're doing. The fact that you're plugging into systems versus reinventing the wheel is ~like~ huge.~ That it it, and it becomes apparently how huge that is. ~The more systems you try to integrate with, cuz then you need custom, custom, this is, and that's at every layer where you want to touch the logs so you can integrate it into any of your existing observability platforms. ~I can still see them with the cli. Is there any way for me to poke at them in the UI if I, if I don't~ Tyson: ~Yeah. Uh, not ~[00:16:00] so the logs themselves know we have some things in the works there today.~ There's a, a dashboard experience for like, the process of going in and actually like, you know, scheduling a or kicking off a logs or batch download. Um, but you know, our, our first party UX around is pretty limited today.~ ~Um, again, You know, I think if, if customers go and tell us like, Hey, in addition to what we're, what we're using on the observability side, uh, with these different tools, I probably should have put Log Rock into that list by the way too, guys. Everyone. But, um, the, you know, that's something that we can, can build, um, in the future.~ But to be honest,~ it's not something we've heard from our customers. You know,~ most of our customers have their observability stack they're using for their application. What they want is not another place to go and look up logs and metrics. They want a way to integrate that with their, their existing tools. That's what we've prioritized. Paul: ~Do you think that speaks to your customer base at all? Because if I think about Firebase, like that's kind of the og, like zero to one document database that came out back in the day where. I mean, that was my first document database. If, if I wasn't a Mongo guy, at first it was Firebase and they're like, Hey, you can throw anything in here.~ ~Great ui. Maybe you're not getting that feedback. Do you think, because like you have a more enterprise professional user base, we're talking about features such as region specific replication, like, like a beginning. Dev doesn't even know what that is. So is there some of that element going on? Do you think that you're gonna see UI crop up?~ ~And~ I'm curious what you think Tyson, your general user base for Fauna right now is. Tyson: ~Yeah, I mean, a great question, very broad question. I'd say first of all, you know, our,~ our existing customers, ~um, run,~ run the gamut, right from, ~you know,~ hobbyists, ~uh, sort of~ early stage startups, especially very forward thinking startups that are ~kind of~ all in on serverless and these kind of modern application architectures. ~Um, you know,~ but we also have customers like h and r Block, Unilever, Santander, ~um, You know,~ a bunch ~of,~ of ~sort of~ larger enterprises that are using the product as well. Really. ~I mean,~ the interesting thing is they kinda, they tend to pick fauna for different reasons. ~Um,~ Paul: ~Oh yeah. Okay.~ Tyson: ~you know, I it~ because your architecture ~kind of~ impacts some of the benefits that you get from the database. ~So, um, you know,~ five or 10 years ago, all applications were being built using this more traditional three-tier architecture where you have, ~you know,~ an app server running in region with your database and then your front end is, or your application. Is [00:17:00] just sending requests to that app server. ~Um,~ today you see ~these,~ these kind of more modern application architectures where logic is just pushed to the client. ~Um, you know,~ whether that's running on my mobile phone or it's running on iot device or desktop, whatever. ~Um,~ and that client is just making direct requests to different APIs. ~You know,~ this has been the case for ~a,~ a long time in ~sort of~ different segments that have been, ~uh, You know,~ where APIs have won. If you think about products like Stripe and Twilio and these types of, ~uh, you know,~ world class products in infrastructure, it's ~kind of ~a new thing. So the fact that you can treat an a database as an api, which is really kinda the highest level of serverless, ~you know,~ that, ~you know,~ put everything behind this API that's a contract between me and you, and don't worry about it, ~um,~ that's huge. And then you also get the performance wins where without you having to think about it. We are, we're automatically routing that request optimally, right? So if you're in Seattle where I'm sitting right now, ~you know,~ instead of that request going to Virginia where my single instance Postgres database sits, ~you know,~ and doing ~a,~ a round trip there, which takes hundreds of milliseconds, ~you know,~ then maybe [00:18:00] I even do some processing on the client. Cause my business logic runs in the client. I do another request, right? All of a sudden you're talking about hundreds or ~um,~ of milliseconds or even seconds, ~you know,~ fauna. Will automatically direct that request to Portland, the US West, ~uh,~ one at US West two. ~Um, and, uh, um,~ and you're talking about suddenly like a 10 millisecond round trip time, right? Much faster. And then because ~the,~ the application model is very flexible, you can essentially push that business logic to run on top of your data. ~So, you know,~ suddenly in these scenarios you're talking about a single 10 millisecond request versus, ~you know,~ multiple. ~You know,~ triple digit millisecond request, and that's a big deal for modern applications that have to be fast, responsive, ~you know,~ the demands, these applications intensive. Paul: And do you feel like Fauna is really coming in to help? processing realtime applications. And when I think of an online realtime application, I think of like an enterprise app or like a chat application or ~like,~ yeah, something with those [00:19:00] like big data needs, which, ~you know, would,~ would make me think that ~you have a,~ you have a lot of enterprise customers and maybe that's why you don't have as much need for ~a,~ a ui cuz people who are dealing with infrastructure, they're like, ~I mean,~ for Terraform, ~I don't,~ I don't know of a lot of Terraform UIs out there. They're out there. Tyson: Yep. They Paul: not, it's not native. Yeah. Tyson: Yeah, ~I mean, I don't,~ I don't, ~you know,~ what we see is, ~um,~ maybe for the, even the enterprises that are adopting us, like a lot of times it's a product team that's ~sort of~ very forward thinking or, ~you know,~ maybe ~the,~ the initial development's coming out of ~like~ a innovation center at those enterprises. That's, ~you know,~ looking at new technologies. How do we modernize our application stack? How do we move faster? Cuz every company wants to do more with less. No company wants to sit there. ~Um,~ managing infrastructure, ~right,~ like we talked about earlier. ~And so, um, You know, I'd say in terms of like how standardized are those companies on things like observability tools, you know, varies company to company.~ ~But I don't know that the delineating line there is kinda, you know, more mature enterprise versus, uh, you know, newer, newer startup. Um, yeah, I think it's across the board, but we, and we do, you know,~ for us, I'd say we do see pretty, ~you know,~ a wide, a broad adoption that, that kind of spans the gamut of those companies, which is exciting. ~I mean,~ it's fun to, ~uh, you know,~ to work with all those classes ~of,~ of companies. Paul: So for 2023, for the next two quarters,[00:20:00] ~I know you said you guys are working on some sort of like logs, user interface, user experience for people to view things in the dashboard. Uh, For the platform and the api, ~what can you share with us right now that the team is working on? Tyson: Yeah. So ~the,~ the, by far, I think the most exciting project that we have going on internally is ~sort of~ a rethink of. The language, which is the language that we expose for interacting with your data. ~Um,~ and so we've actually just this week, ~uh,~ we went, ~uh,~ beta public. ~We,~ we, ~uh, we,~ we opened up a public beta of that brand new language, ~um,~ which is, we spent a lot of time thinking about years working closely with our existing customers. We dog food our own product as well. We use FA internally for, ~uh,~ a bunch of different things. So taking all that knowledge together, ~you know,~ working with, ~um, Uh,~ researchers who were involved in building, ~um, you know,~ modern languages like TypeScript and putting that together into this new language that we're calling fq L x, ~um,~ deeply inspired by both TypeScript and ~Graph Q or and,~ and GraphQL. ~Um, so, you know,~ fundamentally a very type script like, ~uh,~ syntax that'll feel familiar ~to,~ to front end developers, and then abilities to do things like projections, ~uh,~ like GraphQL style projections. ~Um,~ but that's the thing. I'm by far away the [00:21:00] most excited about the language, ~you know,~ to me ~looks,~ looks and feels awesome. ~Uh,~ very ergonomically pleasing, very powerful. Early feedback has been, ~uh,~ has been pretty fantastic on it. ~Um, yeah, so that's, I think, you know,~ you're gonna see more there that, ~that~ we're working on. We're thinking about, ~you know,~ continuing to build on concepts like, Optional schema for your data. So a lot of projects when they first start, you want your data is very flexible. You wanna be able to iterate quickly and change your data model. But at some scale, as an application matures, you wanna be able to make certain guarantees about your data, ~uh,~ and the shape of that data. And ~so, um, You know,~ that's an area where a lot of document, ~uh,~ databases have punted previously. ~And so we're, we're, uh,~ we have this notion of schema where ~we're,~ we're working on, ~um,~ giving developers more control to define and then enforce schema on documents as well. ~So, um, yeah, those are a few,~ a lot of other exciting stuff coming down, coming down the pipe as well. But, ~um, you know, those,~ those are ~kind of~ the two things that I'm the most excited about. Paul: And for anybody listening, they might hear fauna query language and think, oh, ~damn,~ like this sounded cool, but now I need to ~like~ learn another query language. ~And,~ and ~I,~ I know when I was reading about it, it's like, there's lots of powerful things you can do with FQ l ~um,~ but the coolest thing is ~you,~ you don't need to [00:22:00] use that. Right. Tyson: We do support an outta the box graph endpoint today. ~Um, this is what I'd say. So it's a, it's a fantastic question, and~ this is, again, something we, we've thought about ~very,~ very deeply before setting down this road to, to build a, a new version of our query language. ~Um,~ general purpose programming languages, ~like, you know,~ JavaScript type script are not specifically built to, to work with data. They're built to be general purpose. ~Um,~ they're not built to be, ~you know, we,~ we use terms like dq l dml. ~Um,~ for these flavors of ~kind of~ like data languages, that's not what they're built to do. So no matter what, ~you know, you'll,~ you'll see a lot of vendors talk about things like, Hey, don't learn any ql. ~Like,~ just use JavaScript, whatever. It's no matter what, when you're accessing data, you're going to be using some kind of a query language. That query language may be defined in what's called an embedded dsl, where it's a library that ships where you have to learn this library and what it looks like. ~You know,~ and it borrows ~kind of, uh,~ semantics from ~the,~ the host language, but it's still, no matter what, it's a lang, ~it's,~ it's a language, it's a DSL that's, ~uh,~ usually, ~you know,~ somewhat, ~uh,~ [00:23:00] tightly coupled to the underlying data model in the database. So, Paul: we think like Prisma and the way I query Prisma, like it's its own Tyson: ~Yeah, I'm not a prisma. Yeah, for sure. I'm not a prisma expert, you know, or different, or m implementations effectively kind of, uh, define. Yeah, yeah, for sure. No, we, I mean,~ I should say Prisma is obviously very cool. We have a lot of customers coming in talking about Prisma support fauna, which is something that is on our roadmap a little bit less clear, ~you know,~ how you map uhms to. Document database where we're already storing data as objects, but it's definitely, ~you know, for sure a,~ a very compelling technology that people are excited about. ~Um, but, uh, but yeah,~ so I think that the more general question becomes like, what is the most natural way to let developers interact ~with,~ with their data? ~You know,~ given the, this kind of underlying data model and for us, ~you know,~ the prior version of FQ L was actually implemented as an embedded DSL where ~you, you know,~ we ship this as libraries in different languages. ~Um, you know,~ we've actually gone away from that to something that is ~sort of~ a pure DSL where that has its own syntax. ~Um, you know,~ we'll have things like language service support ~and,~ and deep integration into IDs. So you get all that goodness and teles sense and things that you're wor you're, ~uh,~ you're used to, ~you know,~ for a first class developer experience, ~but you know,~ it's portable. You can take it different. You can write a [00:24:00] query, you can take it different places. ~Um,~ and again, feels very familiar to front end developers in this world. Very natural in terms of ~the, the,~ the shape of the language. Paul: When you're designing this dsl, Do you feel like you and the team have arrived at some realizations about maybe something that was an assumption or an oversight in the original design, say of~ like~ Postgres S ql dsl or Mongo DB S SQL L, that you were like, we wanna address this issue, and we ~kind of~ didn't realize it was gonna be an issue, but now we see it and we're gonna ~like~ build it into a feature full, what is it now? ~Uh,~ fq, L x ~in the,~ in the next version? Yeah. Tyson: ~yeah, for sure. I mean, you know,~ we obviously, we spend a lot of time looking at other quarry languages. ~You know,~ Mongo's MQL is implemented as an embedded DSL where they ship drivers in these different languages. And ~you know,~ like we talked about earlier, the expression of that is in these drivers. ~You know,~ one thing that we spend a lot of time thinking about, sort of relative to, ~you know,~ other players in the space like Mongo, is how to naturally express. [00:25:00] Relationships across, ~you know,~ entity types defined in documents. And so FQ LX has this awesome, ~like, you know,~ just dot chaining syntax where, you know, you, you can, I can say, ~you know,~ person dot address, dot whatever. And basically, ~you know, you're,~ you're effectively doing this kind of implicit join. ~Um, you know, not,~ not creating a single entity type, but ~you're,~ you're navigating across entities based on these relationships in a way that just feels so natural for. ~You know,~ how we're used to doing this, ~uh,~ in like modern programming languages. And so that scenario we invested pretty deeply in, ~you know,~ SQL is a whole different, sql, ~uh,~ is a programming language that obviously, ~you know,~ has been around, ~you know,~ for 50 years now, 50 ish, something like that. ~Um,~ it was initially built for these analytical use cases where you had humans querying a database and then a lot of functionality ~kind of~ evolved from there. ~Um, you know,~ that's not how transactional. Databases work today. It's an application, ~you know,~ talking to your database to get your data. And so in practice, what you have for all these SQL databases is, ~um, you know,~ they're using ORMs, ~um,~ on top of sql. And so because you [00:26:00] have this kind of object, ~you know,~ relational what relational impotence, mismatch. Where the developer speaks in terms of objects, but the database speaks in terms of tables. And so you have to translate that somehow, which sounds good until you start going down that trail. ~You know,~ in practice what happens is you end up with performance issues and then you're trying to debug, okay, how is the om translating my query to sequel? Then how is the sequel optimizer deciding to execute my query? ~Um,~ and it's this whole rabbit trail where, ~you know,~ I think it can be a huge gotcha in terms of application performance at real scale. ~You know,~ whereas with fauna, there's no translation. You're speaking in terms of objects ~all the way,~ all the way through. ~Um,~ and most of how you're defining queries, ~you know,~ I'd say especially in fq lx, ~sort of, you know, um,~ declarative versus imperative is not ~a,~ a binary thing, but ~you, you're,~ you're defining ~your,~ your query in a somewhat imperative way where it has predictable performance as well. So big win for your application as it scales. Paul: And if there's any developers out there who maybe use, ~uh,~ an existing database, let's think of ~like~ a relational use case, like you're [00:27:00] making your next big million dollar app and you're listening. To this podcast and you're thinking, wow, that all of this sounds cool. Like region replication sounds cool. The database is a service serverless. Sounds cool. ~If,~ if we want to think about, ~uh,~ less on the service side and more on how we're storing data and the way we're evolving our data over time, what would you tell that developer to pique their interest and maybe advertise the possibilities for their engineering scope in their application to Tyson: ~Yeah, I, I mean,~ I guess I would just say if what you want is to focus on your application and build as fast as you can, ~you know,~ you're, you, presumably you're building a niche for of competitors that are gonna come along and, ~you know, and,~ and speed is gonna be of the essence. But then I think you are well served by looking at a database that. ~You know,~ in the near term takes as much as many of those concerns away from you as possible. So you can innovate quickly, but in the long term, ~you know,~ is also proven to scale. So you're not gonna end up in a situation where, you know, all of a sudden you're running on single instance Postgres [00:28:00] and ~you know,~ you realize that your app is scaled way beyond that. And then you have to think about things like a big data migration. ~Um,~ and yeah, ~I guess, you know,~ I'm clearly biased, but I think Fauna, ~you know,~ provides a very unique, ~uh, uh,~ value proposition on both of those dimensions. ~You know,~ get started quickly, create an account, ~you know, uh,~ start playing around in our free tier. ~You know,~ we have ~sort of~ a generous, ~you know,~ free tier that then gets you into progressive pricing as you,~ as,~ as you scale, ~um, you know,~ and take advantage of all those capabilities. Don't think about infrastructure, don't think about patching, scaling, ~um, You know, just,~ just focus on your app and then know that we're gonna be there for you as well as application. Paul: And it seems like that's one of the big things that's at least exciting me as a developer myself, is the capabilities like with FQ L. If I can think about my data models in a more native way that's not translated through an rm, maybe I can think of ways to speed up the app that I like maybe never would've thought of. Tyson: Absolutely. Paul: I spend so much time thinking about ~like~ what foreign keys are gonna relate to which ones, and ~like,~ do I want to pull all this data? When do I not want to? So~ just the pure fact of like, hold that light, like don't stress, let's rethink about~ this ~in a more type, safe and like modern way~ [00:29:00] is very exciting. ~Very~ Tyson: ~yeah, yeah, for sure. Yeah, I mean, just that, you know, something you touched on there, which is not,~ not needing to understand access patterns for your application upfront. Is a huge deal, right? Because if you look at, say, dynamo for example, ~um,~ and you look at all of these different patterns that are emerged, like single table design, at the end of the day, they're all hacks. ~You know,~ we're working around some of the limitations that are out there with Dynamo. I say that as someone who, ~you know,~ used to work at AWS and has built a lot ~of~ of stuff on Dynamo, you know, great database for specific use cases, but you really have to understand how that data is gonna be accessed. And then ~kind of, you know,~ optimize for that. And then it's hard when you go to build feature number two. Feature number three, ~you know,~ that can be tricky. I think fauna, ~you know,~ is with fauna you can do things like start, build quickly and then know that pattern as your application Paul: Arbitrarily. Tyson: future.~ So, yep.~ Paul: ~Awesome, Tyson. Well, if people want to keep up to date with you personally, uh, like do you post on Twitter or Medium or anything if people want to see what's going on at Fauna, a little inside window.~ Tyson: ~Yeah, yeah. I'm out there on Twitter. I don't post, I, I admit I'm not super active out there, but Tyson Troutman, uh, on Twitter, I'd say the best thing is, you know, I do write, uh, con I think there's some awesome content that hits our, uh, fauna blog and gets posted on Fauna Twitter. Um, you know, not only about us, but kind of about the space broadly.~ ~So that's a great place to go and, uh, check out if you wanna follow along with some of the interesting things going on at Fauna and in the broader, uh, database ecosystem.~ Paul: Awesome. ~Well,~ Tyson, thank you for your time coming on and getting to riff a little bit about databases ~and the, and the space as it stands right now.~ Tyson: Yeah. Yeah. Paul, it was my pleasure. ~It was a lot of fun. Uh, nerding out a little bit. This was great.~