Ben Edelstein: Hello, and welcome to Pod Rocket today. I'm here with Monica Sarbu. Who's the founder and CEO of Xata. Is that how you pronounce it? Xata X-A-T-A is how it's spelled? Monica Sabru: The idea is to be like extended data. So it's like data, but there are two pronunciations Xata or Xata, depending on where you're living or. Ben Edelstein: Xata or Xata. Got it, I like that. Well, very excited to have you on and learn about Xata. Could you give us a quick overview of what you're building? Monica Sabru: Yeah, thanks for having me. So the idea of Xata is that we are building a serverless database that aims to radically simplify the way developers work with data. So the idea basically came, if you think like if you are working in an organization and you want to start a new project, the idea is that, first you need to kind of look for a way to store your data and then you have to have all these discussions, what kind of database should I use? Should I use NoSQL, MySQL? What kind of SQL I need to use? And if SQL, and then the idea is that as your project evolves and you also want to have a search functionality into it, and more often you use something like Elasticsearch. And for that, you have to synchronize your data from your data base to Elasticsearch, and you need something like Kafka to be able to do that. Monica Sabru: And then yes, your project grows, then you also have to add another caching layer, something like Redis. So as you can see, the whole data infrastructure becomes quite complex. And this is something that I realized that many companies are struggling with. So my idea is why every company out there needs to re-implement the wheel instead of having all this functionality against a single API. One API that you can use to insert the data into the database, query your data and search for the data that you are looking for. And this is basically how I started the idea of Xata. Ben Edelstein: Got it. And under the hood, are you using a Postgres or Mongo or like what type of database, or did you build something from scratch under the hood, in terms of the core database layer? Monica Sabru: So our idea was to not start a database from scratch because a database is not something that you can build overnight is something that takes a lot of resources and effort from your side. So our idea was to build a solution based on other existing solutions. So we are using Aurora more precisely. So we're using PostgreSQL and also Elasticsearch and a bit of other services out there in order to build all this functionality out there. Ben Edelstein: Got it. So you're building on kind of a stack of proven technologies, Aurora, Elastic, curious what you, you mentioned caching as one of the maybe problems you're trying to solve that every normal people have to kind of deal with on their own. Do you use a caching layer as well? Monica Sabru: Yes, currently we don't have, but we are planning to add something like this to have the whole picture. Ben Edelstein: Got it. So Aurora for database Elastic and then eventually a caching layer and what does a developer get if they use Xata instead of just, if they kind of manually implemented all of those tools on their own? What is the kind of the value add of your product? Monica Sabru: Yeah. So one of the things that I've seen is that companies and startups, for example, are spending more than 50% of their resource building on data infrastructure instead of them concentrating their resourcing on building the functionality, the business logic of their product, right? So that's why we want to make the teams and companies more efficient and provide all these functionality against the single MPI. Also another thing that I realized in my career is that, imagine the big technical companies out there like Elastic and so on, Google and so on, for them it's very easy for them to attract good technical people in order to be able to build such a data infrastructure, because this requires really complicated, complex knowledge of all the services. Monica Sabru: But for other companies that maybe it's harder for them to attract with technical people, especially companies that are not so technical oriented, they are not building technical products for them, it's very difficult to attract good technical people. So the way it's happening is that they are going to outsource building the data infrastructure to another company. And as you can imagine, as a result out of this is not a good one. So one of the things that I have realized is that, there are lots of companies out there, they are building their data infrastructure or the way they store the data with Airtable. So they're using as a data store. And I've seen so far discussing with lots of companies that people are very innovative in how to overcome the limitation of Airtable, they have hundreds of Airtables, they synchronize between them and so on. They build a lot of custom logic on top that at some point becomes this monolithic application. Monica Sabru: So the idea is that companies decide to go with Airtable because it's just the easier solution to get started. This idea that once they find the product market feed, they're going to replace it with something more robust something like PostgreSQL. And I can imagine as a company, how does it feel to move from something that is so easy to use as Airtable to something that is so complicated to use as PostgreSQL. And for me I realized this only when I started Tupu, so I started Tupu this non-profit organization that offers free mentorship for underrepresented groups in tech. And we are building a platform, a mentorship platform, and we realized there isn't really a database solution out there that is as easy as should be. And you have to spend a lot of time trying to understand how a database work, you need to read documentation, then try to understand how you can fit your database into your application. Monica Sabru: So that's a lot of work. And in the end, we decided to go with Airtable because Airtable was very easy to build a solution in just a few weeks. And also we use Airtable as the CRM type of tool in order to do the matching between the mentors and mentees, because we are still doing this manually. And this was kind of the moment when I was on the other side of the table, kind of realizing there is a huge need on the market to have a database, a serverless database that is very easy to use that offers a developer experience and basically changes and provides all the functionality that you as a company need. So you don't have to provide and implement or spend a lot of resources concentrating on building this complicated data infrastructure that kind of every company out there as using the same tools and has the same architecture over and over again. Ben Edelstein: Yeah. I mean, makes a lot of sense. And I've also spoken to numerous startups where they build their prototype on Airtable, and it's great because it's fast, it's easy to get started. They have the really nice kind of GUI on top of the database, essentially, which is for Airtable, it feels like their product is primarily a GUI with kind of a database under the hood, but that's where a lot of the magic is, and being able to quickly tweak your schema or create fields or edit data just in a nice visual interface. And then you can build your product on top of their APIs and I hear about that a lot. But to your point that never scales beyond some certain capacity because it's not a true database, that's meant to power an application, or at least that's my understanding. So this makes a lot of sense. And are you building a full visual editor on top of the Aurora database? Like something that's similar to Airtable? And if so, maybe curious to understand how it's similar or different than what folks are used to an Airtable today. Monica Sabru: Yeah, so I think in my opinion, Airtable is door opening for a new era where users seen how many complete caged things they can do with such a great user experience with such a simple UI. And you don't have to be even a developer to be able to group and manage a certain type of data yourself. So the idea is that what we are trying to build is that we get the usability of Airtable and we put it on top of a traditional database. Without removing the key features of a database like data integrity and scalability. Monica Sabru: And so, yeah, as you said, we are building a similar view as Airtable has with a special IQI because this is a really easy way for you to see data, but also to build your schema file and update your schema or your Schema not file or your Schema. And yeah, and the idea that we have is that we put a lot of effort in trying to kind of think of like, what is the best and easier workflow for our users to become successful and start and run a database, even in production with just a few steps. So, because we kind of we want to change the way developers interact with database currently. Ben Edelstein: One of the things that I remember, I used Airtable for a project a few years ago, so it's possible they've solved this problem, but, if you're trying to change a large amount of data or change the format of a whole column, there wasn't a ton of tooling or much of a story around a migration. So is that something that you automate where if you, in your visual editor want to change the schema or format of a column, can you do those migrations automatically on top of the Postgres database? Monica Sabru: Yeah. I mean, you have to understand that Airtable was built with a different use case in mind with a different persona in mind, right? So our focus is we are concentrating on building a solution for developers, and that's why we introduce branching, which I find it very interesting, a very interesting concept in the way, imagine that you want to build a new feature and for that, you have to create a full request in GitHub. And I think it'll be nice to be able to have, let's say a button or a link in GitHub that says, "There's this new feature against the new schema and against real data from the database. And if this goes well, then deploy it in production." Monica Sabru: I think in my opinion, branching is like a feature that is specific for developers and idea is that you have your brand, you create a new branch, then you create the migrations and then you create the migration request to deploy all these migrations into production, without a downtime. So the idea of having a zero downtime migrations, it's something that is very powerful. And this is the hardest thing that we are building for a type of database that it's a schema for LIPO database. So we are building a solution, a database solution if you want, on top of other database solutions, but we are building a lot of functionality on top of it in order to make this experience as easy as possible. So even though you are not a developer that needs to understand how a database works in order to be able to run one in production. Ben Edelstein: I'm curious you mentioned on the website, I was just looking at it, and we talked about this before, one of the benefits is that it's as a serverless database, so to speak, folks don't need to worry about scaling of the database and nodes and all of kind of those concepts. But at the same time depending on what an application looks like, it can be helpful to have some control over how cost scale, or how performance scales as a developer when you're building an application. So how do you think about that trade off of giving developers control of the underlying infrastructure, such that they can kind of tweak things as necessary, but also making it as easy to use as possible and accomplishing your goal of just making something that's extremely easy for developers who don't want need to deal with Elastic and Aurora and all the underlying tools? Monica Sabru: Yes, that's a very good question. I mean, this is something that I was, this is, I mean, in my entire career, I was building tools for developers and you always have this, I think the perfect answer on this is that you have to find the balance in order to make it, build a solution that is as easy to use as possible, but also that allows you to be customizable in order for bigger organization or larger organization, to be able to kind of fit in their infrastructure. Emily: Hey, this is Emily, one of the producers for Pod Rocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan U and Rich Harris. In return, we'll send you some awesome Pod Rocket stickers, so check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show. Ben Edelstein: So there's been a ton of innovation in this general space. I mean, all the serverless platforms and then kind of on the storage and database and tooling for serverless side, we've spoken with Supabase and we've had a few folks on the show building platforms for developers of serverless. So curious how you think about the competitive landscape and how Xata compares to maybe something like Supabase since that's maybe something our audience is quite familiar with? Monica Sabru: Yes, that's a good question. So the idea that we have is that we want to build more than a database because we are providing more functionality. So that's why there isn't really a direct competitor out there on the market that is building something similar as we do. Of course, if you think about the database, because in the way, people are going to associate you as a database. There is lots of competitors on the market, right? And now like you mentioned, there is a Supabase also that is building a serverless database, the difference between Supabase and all the others is that. So their idea is to get MySQL or PostgreSQL and offering as a service. And basically they are allowing direct access to PostgreSQL or SQL to the users. Monica Sabru: Our approach is a bit different. So we want to think about, what will be the ideal user experience that the developers can have and then think about backwards, and that's why our solution is that it is built on top of other existing technologies, but if the users will interact with the API. And this allows us to build features that the others are not able to build, because they're limited to the PostgreSQL or the other SQL APIs that they have. So that's why we can discuss about zero time migrations and things like this. Monica Sabru: In the last year, there are a lot of innovation in the UI world, if you want. So now it's very easy to deploy web applications with platforms like Netlify and Vercel that makes it so easy, we just, by pushing your code in, we get... And I think what's missing is the data part, because currently it's so complicated to use and integrate databases. And I think if we have this part and we'll give superpowers to UI developers to be able to build applications, end to end applications, dynamic applications that they were not able to build before. So I think this is one of the target audience that we want to start with, because I think this is where we think we can bring a difference or something innovative into the space. Ben Edelstein: I'm curious to learn a bit more about your API. So from what you were saying before, it sounds like developers aren't interacting directly with the Postgres API. So what does it look like to use the Xata API? Monica Sabru: Yeah, so it's very similar if you are familiar with Elasticsearch API, because a few people from Zaytech came from Elastic, including myself. So we got inspired quite a lot from Elasticsearch, but based on our experience of course, we made the V2 version of Elasticsearch API. So it's very easy to use. And we also, in addition to the API, we have two ways basically for you to interact with your product, with the service, either through the common line interface or for the UI that we discussed a bit earlier. Ben Edelstein: And if someone wants to use an ORM like a Prisma, are they still able to do that with Xata? Monica Sabru: They are. That's a very good question. The idea is that you don't need to use a URM on top of it, right? So maybe we can think of like having an integration because Prisma, for example, is building integrations with a few other database into the space, so we can have an integration with them. But imagine that, for example, it's a comparison with having PlanetScale and Prisma together. This is what we are billing. And on top of that, we also have our SDK because all the others because they're exposing either PostgreSQL or MySQL, depending on the company, they can use all the ecosystem that is available our layer, but we build our own SDK in order. And basically, as you can see, we are building all these pieces with the idea to build end to end user experience better for the developers. Ben Edelstein: You mentioned before, one of the advantages of using the Xata APIs, you're able to support zero time migrations. Could you explain a bit more what that means? Monica Sabru: Yeah. So basically what this means is that you can basically imagine that you are building a new feature and then you can deploy in production without having your system down for the time of the migration. Ben Edelstein: Got it. And I guess, would there be any concerns with something like that a developer could accidentally make a mistake and delete data, or have a migration, if the migration's happening automatically under the hood? Like other concerns a developer would have to be aware of? I feel like when whenever tools abstract some of these core underlying concepts like migrations or transactions, on the one hand you gain ease of use and speed of development, on the other hand, maybe there's some additional risks that things could go wrong. If the developer isn't explicitly telling the database how to change the data and what to do. So am I thinking about that right? That there maybe are some trade offs there and any ways that you're addressing that problem? Monica Sabru: I think that's basically one of the main benefits of exposing an API, because you can restrict what the user can do. So basically it is like if you expose directly the PostgreSQL for example, you cannot really restrict any functionality, but because we have our own API, we can allow this. And for example, we can have, other engineers from the company can review the code before deploying production or things like this in order to make sure that this is safe. But this is idea of branching, right? Because when you create a new code, for example, and then the idea is that you can test it against the new schema and against your data from the database. So there are lower chances for you to kind of make any mistakes when you deploy in production. Monica Sabru: Currently, this is unfortunately, it's kind of a manual work for the developers because usually they sometimes test a new feature against the real production database out there, or if they have another development, a copy of the production database internally, but it's kind of a manual process. And we want to make this as easy as merging your pre quest and gift. Everything through a UI, everything just very easy and yeah, just reducing a lot of manual work. So you, as a developer can concentrate on building the important features that you should be concentrate building on and not necessarily in like how you test things and things like this. Ben Edelstein: So I'm curious to learn a bit more about the future roadmap, we spoke about how caching is coming up soon, but curious both short term, like next six to 12 months, what's on the roadmap? And then afterwards, we can kind of talk about five year vision, what are you most excited about? But maybe we start first short term. Monica Sabru: Yeah. So we didn't discuss about this, but currently we are, in closed beta. So two months ago, we started to onboard our four users. And the plan is to have a public launch by the end of the summer. And basically we'll kind of contain all the functionality or that we already discussed about. And long term plans, let's say the first phase for us is to concentrate on web developers. And that's why, like I said, we are very excited about this integrations with Netlify, Vercel, and also we are discussing integration with Cloudflare workers. I think there are so many integrations that we can do that allow users to build even applications end to end. Monica Sabru: So the second phase that we want to concentrate, or then backend engineers would be basically one of our target audience as well, and kind of long term, but not necessarily long term, will be that we also extend to non-technical people. The way I'm thinking is that imagine that you have a company and the developers from that company are building their web application on top of Xata, and then you have to imagine that you have this data database that's towards all these data that are collecting from the users. Monica Sabru: And then you have all the other departments inside the same company, non technical people, like for example, marketing and so on. They would like to build a CRM type of tools on the data that you are collecting in the database. So the idea is that to use the same service, but for different personas, of course, different functionality. But the idea that we want to achieve here is that we have single service that you can use by different personas. And this is very useful in the case, imagine that you are working in support for example, and you want to have a specific view of the data to be able, for example, to be allowed, to change only a column, for example, the address of the user, or for example, a coupon or things like this. And that will allow you to directly change it into the database. Ben Edelstein: And then how about longer term where do you see this going in five or 10 years? What's the vision? Monica Sabru: So the kind of the longer term vision is that I think we are in a very lucky situation in the sense that we own the data so we can build a lot of functionality on top of it. So the way we are thinking of is that in the future to allow users to build end to end web applications, not only the database part, but also the whole picture, I think what we think it is kind of lacking at the moment is that it's very hard for you to copy a feature from one web application to another. And the way to do this is that you have to copy the web, the whole web application. So I think it'll be cool to have like a platform that basically will allow you to build this new web application with just selecting the common functionality that all the web applications have, for example, billing, out in the vacation and all of this, it's common in all this web applications. Monica Sabru: So you don't have to reinvent the wheel every time you are building a web application. So definitely there are other companies out there that are doing something like this. So initially probably it'll make sense to integrate with those companies. But I think the power will be to kind of provide an end to end user experience for building an entire application. I think my theory is that I think it's already so difficult to find good technical people, and we are at a stage, let's say where we need to simplify the way developers build new applications on top. Monica Sabru: And I think you don't have to be even a developer to be able to build an application yourself, imagine that you are starting a new company and you are not a developer. I think there are so many companies out there that the no code, low code type of market. And I think in my opinion, this is a trend, so it allows you in the end to build a whole company with just a few resources and will give you more time to also concentrate on what is important for your organization. And I've learned this in my career, no matter how big is your organization, you will always struggle on the number of resources you have. So there is always like this. So I think it'll be good to use let's say data infrastructure out there, or use different services, this service for authentication, this is for storing the data, this service for something else, that allows you to build end to end application with just few resources and in a shorter period of time. Ben Edelstein: Well, Monica, thank you so much for joining us today. It's been great learning about Xata and we'll post some links in the episode description, the website's just xata.io. Any other resources you would recommend for someone who wants to learn and get started? Or should they just go to the website? Monica Sabru: Yeah, I think go to the website and also go to our documentation. If they're curious about, I think I will suggest to subscribe on the waiting list and if you have a use case and an urgent use case, just reply to the email that you received from us, and we're going to allow you to the closed beta version, we love to hear your feedback. Ben Edelstein: Awesome. Well, thanks again, Monica and take care. Monica Sabru: Thank you. Bye. Speaker 4: Thanks for listening to Pod Rocket. You can find us at Pod Rocket pod on Twitter, and don't forget to subscribe, rate and review on Apple Podcast. Thanks.