Building The Database That Can Do It All | Tobie Morgan Hitchcock, CEO of SurrealDB

Thank you for having me here.

This is the very first podcast I've ever been on. Done lots of streams, done video interviews, TV interviews, but never a podcast.

So SurrealDB is reimagining databases. So effectively, the tool that people use to store data and then, once they've stored it, to query that data. The thing about SurrealDB is it makes it much simpler in terms of querying that data, and it means that you can reduce the number of databases that you have to work with as a developer, as an engineer, or as an organization by consolidating different database types together into one single platform that reduces cost, reduces development time, reduces the management of that application or that system as you go forward.

So there's lots more to it, but in a nutshell, it's about simplification of the data backend.

I'd love to say I wrote 300,000 lines of code on a weekend, but no, it didn't happen like that, unfortunately. So if you look at many databases out there, they're improving slightly on one particular thing. They may be improving on performance, or improving on what you can do with your data, or how it runs in the cloud, or something like that. But with SurrealDB, we had to reimagine many different parts of the database in order to make what SurrealDB is today.

I guess where we start is why I decided to build SurrealDB in the first place, as opposed to how we started building it. So we were running traditional cloud applications on top of many different databases in a similar way to how other organizations are still doing it today. So, a time-series database, a document database, a graph database if you're doing analysis over related or connected data. And then we also had a relational database in the mix as well. Most organizations do.

Yeah, exactly. So we had a number of different products that we were building the technical side of. And in doing so, we wanted to simplify how we could do that so that we could run these applications efficiently without that much effort, as it were. And that was how SurrealDB came about. So we were using these different databases, and the management of that in terms of managing four different databases, even in AWS, ensuring that they're up, working as you want them to be, updated in the right ways when you're updating your application, that becomes time-consuming and complex, and we wanted to move away from that.

And we wanted something simpler. At the time, there was Firebase, and Firebase enabled you to connect to a cloud instance and store your data and connect to it directly from the web browser and build your applications against it. But it was incredibly limited in terms of how you query your data. And today it's still limited in a similar way, that it's not really a database. It's what I would call a data platform or a data layer. We wanted to build a database that gave you the total flexibility to run your queries as you wanted to in your application, but with the same functionality that something like Firebase offered, but then also still act as a traditional database backend for those who needed that as well.

It was actually funny. So my very first conference I spoke at was RustConf London. The entirety of SurrealDB is built in Rust, and we'll come to that a little bit later. But the first question we got from the audience was, look, it takes a long time to build a database. How did two of you build it? So it's actually only one of us. My brother is the marketing, the branding, the design, everything behind SurrealDB, but not the code.

Yes. So it's just one person, and it was seven years in the making.

So interestingly, I don't come from a database background at all. So I think if you were to have come from a database background, you probably wouldn't say, yep, we'll rewrite the entire database backend.

Exactly. I think it was coming from a point of view of not actually understanding what was needed at that point. I'd had a lot of experience with lots of different database types, database internals, the codebase of many different databases, but I'd never really written my own. Definitely not. And I started with—so my master's thesis was in key-value stores and focusing on the performance of key-value stores when you're dealing with temporal data. So not just time-series data where you can order events by a timestamp, as it were, but actually temporal data, which enables you to go back in time and see data as it changes over time and gives you the ability to run entire queries over entire datasets as it existed at a particular time.

So almost like a third dimension to your data. That was where a lot of my interest lay, and I did my master's thesis on that. But when you look at the power of what time brings to data, you can do so many things with it, but there's not a single database out there designed in that specific way to be able to do that. And that is where the idea for SurrealDB came from. And at that time, we wanted to reinvent this wheel.

And many people say, well, why? Why do you need to? Why do you want to reinvent the wheel? Because if you want to add things like this temporal querying or the ability to combine multiple different types of data and querying into a single platform, you have to rethink how you do that. And so we started that in 2015. From a code perspective, I started that in 2015. And I think it was about two years later that we started using that in our first application.

And I remember launching it on an e-commerce store, and we had a lot of visitors on that e-commerce store, and it just crashed instantly. But we went from there. And then eventually it was doing hundreds of thousands of queries effortlessly and on a single node. And we built from there.

Probably not. Definitely not. There's a blog post—I think it's a famous saying. There's also a blog post which was published, I think, in 2021 or something: "It takes 10 years to build a database." And when we actually launched SurrealDB as an open-source tool and it took off online, it had only been seven years in the making. And in the database world, you're not finished. You're never finished. You've always got to constantly improve and constantly build on top of that.

But to see how users were enjoying and liking the aspects of what we'd built in SurrealDB, and then starting to use it in their organizations, that was kind of the turning point. So, seven years. But no, I think in the beginning, especially in the early days when you're running applications on it and you're trying to work out, at the same time, how to make the load work so that you can cater to the number of queries per second that are coming in, it's a great problem to have, of course.

But it's also a massive learning curve. An enjoyable learning curve.

Probably not. Probably not. I don't know what it actually refers to, but yeah.

So SerenityDB was entirely written in Golang, including our own data structures, which were custom data structures to deal with time in the key-value underlying storage engine. And then, in addition to that, we had the entire query engine, its own parser. Everything was handwritten. It was built in Golang. But we reached this point where we were having to—Golang's changed a lot in the last few years, so a lot of these may have been improved—but we were reaching the point where we were battling against the compiler itself and the language itself.

We were building a lot of custom data serialization and data deserialization logic. As I say, the parser was written from scratch. We were still fighting against different aspects of the language to make it work according to how we wanted to make it work. And there's the idea that you build it, you get it out there, and then you improve from there. But we didn't want to release a tool which was working, but it wasn't working quite how we wanted it to work, and it wasn't working in the right direction to where we wanted to go.

And so we made the decision to completely rewrite the entire codebase from Golang into Rust.

Just to make it a little bit harder. At the time, I'd never written in Rust. I'd dabbled, I'd tried it, but it was new to me at the time. But it's very hard once you've launched an open-source product, especially one that you think, or you hope, is going to take off, to then go and completely change every aspect of it. What you'll see with other databases is they then design parts of it in Rust, and then gradually more and more of that becomes Rust over time, and maybe some of it doesn't.

But it's much easier when you go forward from the basis of everything being built in Rust. We can now build a team of people around the Rust code, and we can go forward in a much easier way. So that was the idea. And it also benefited us because the Rust community is amazing, and you've got some incredible engineers out there. And that helped us when we launched.

Yeah, you'll be interested, like, the number of people who interchange those words. And I guess you can, in a way. It is multi-model and it is multimodal, but—

Well, I do. I'm not sure it's all right. So multimodal is about dealing with different modes, so images, audio, video. Model, I guess, is a different way of saying it, but it's looking at different ways of, in the database sense at least, it's looking at different ways of querying and storing different types of data. So in SurrealDB, you can store traditional document data, and it is a document database under the hood. So it's storing records that look a bit like JSON, in a way.

You can then improve and augment that data using graph techniques. So we'll come back to what graph is in a second. And then time-series data, so effectively a stream of events tagged with a timestamp, as it were. I think the interesting thing that people find when they come to SurrealDB, because you have graph databases out there and you have document databases and you have time-series databases. Just to add to that, you can also query things in a key-value-like way.

So if you want to get a single record, it's very efficient in just getting a single record, which is great in certain industries where they want speed and performance. And in addition to that, it's got an SQL-like query language. So it's very similar to traditional SQL that you might find in a relational database, but it doesn't have joins. And so when people come to SurrealDB, they usually come from the perspective of a relational database, which is tabular, or a document database, which is tabular, albeit with nested fields.

And they usually have to relearn how they insert their data and manage their data in those different types of databases. What they find when they come into SurrealDB is you can start with your data in that way, but then you can augment that with relationships. And actually, relationships and graph is really the way that humans think about the world. So we think about the world in terms of types: people, animals, orders, items, products. But then we augment that with relationships.

So I know you, you bought an item. And when you think about it in that way, modelling your data in your application or in your database, when you can deal with traditional tables and collections of data, but then you can bring relationships into it, makes a lot of sense. So bringing these different models together in a single platform, but not forcing you to have to use one model or the other. You can use all of them at the same time. You can start with one, you can build on that.

You can start without any structured schema. You can improve and add structured schema as you go along with your application. It has a lot of flexibility to it, and it makes sense to a lot of engineers, regardless of which database type or which experience they've come from before.

Yeah. It's a transactional database, so it is designed for reads and writes, as opposed to an analytical database, which is traditionally more read-heavy over large amounts of data. But there are two core things in SurrealDB that set it kind of in the middle as a hybrid transactional analytical database. And that is, the first thing is the storage layer of that data is separated from the compute layer. So SurrealDB can run as an embedded database like SQLite, it can run as a single node like Postgres, or it can run as a distributed cluster.

And you can scale this storage layer and you can scale the compute layer. What that means is if you've got large amounts of data, you can scale that independently. And then if you want to have lots of reads or you want to be doing lots of analytical queries, you can scale the compute layer out and then scale it back down as you need to. Or vice versa, depending on the needs of whether you've got lots of reads in your application, lots of writes in your application, and so on.

The second thing is when you combine traditional row-based data or document-based data with graph and you model it in certain ways, you can actually perform very powerful real-time analytics. So the word real-time has many different meanings in different technical environments, but effectively you're able to perform an analytical query in an expected amount of time. So instead of having to run this query and it takes a certain number of hours and you can process something for the next day, you can actually run queries and get back results very, very quickly.

So combining the transactional approach, which is when you insert data in the database, you know it exists there and it exists for everybody else reading that data after that point, but also when you want to run analytical queries using key-value or time series or graph or traditional, just row-based tabular data, it's very powerful. It enables you to mix and match those different types of queries that you might need in an application or in your backend, as it were.

Yeah, so the separation of storage from compute is an important part in that. So being able to scale those out dependent on what you need in your application. The biggest change in SurrealDB is how we deal with the IDs of documents. So in Postgres or a relational database, something like MySQL, you traditionally have an ID field, which is an integer. So 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, and so on. And you can change that, but that's pretty much how it's initially formed.

In something like MongoDB, you have an object ID, and that is a string, for instance. And then graph databases are slightly different. But in SurrealDB, the ID is made up of the table name that the record belongs in and the ID itself. So that ID can be a number, it can be a string, it can be a UUID, and it can be something more complex, which I'll come to in a minute. By changing that one small piece of technology enables you to bring all these models together.

So if I want to do very quick requests to get just one record from the data store, maybe I'm in ads and I need very quick response time for a very particular record, I can go and get person Toby, and I don't have to use an index. I don't have to know anything else about the data. I can just go and pull that record immediately from the store without having to access anything else in the table. When you use that inside, that ID can then be pushed into documents as well.

So when you use that inside other types of queries, you can then say, look, I have an orders collection inside this record, and the orders has 3 IDs. They point to the order table, and therefore I want to find out which orders this user has made. I can now fetch user Toby, and I can fetch his orders, and you're now going to get 4 records. That's graph. You can then go a step beyond that and you can say person Toby ordered product laptop, and then you can traverse bidirectionally between those 2 different types of records.

If you look at a lot of organisations, they are actually storing a lot of these. They're either specializing in different database platforms. They've got time series databases, they've got graph databases, and they've got traditional document and relational. And often you have to have people expert in those areas, in those different databases. And then you have to make sure that your application, your middleware, or API is connecting to these different database platforms and bringing that all together. And people often look at the performance of one database and they say, well, this is really quick for document data, so you're not going to be able to compare.

But they don't look at the overall platform, as it were, the overall architecture. And when you're having to combine time series data with graph, with document for a particular dashboard or an API, then you have to start taking into consideration all of the performance of all of the platforms put together. Coming back to what I was saying before, a lot of people say you can't get the performance when you're dealing with lots of different models. But because of this record ID that we have in SurrealDB, we're able to have good performance from a key-value perspective, have good performance from a document perspective, bring graph into that and have good performance in the same way on graph.

And then for time series, we go one step further. So the ID, which I said before could be an integer, a string, so a number, a string, or a UUID, can actually also be an array of values. So now I want to create a temperature table, and the temperature table has—each record has its ID, has an array, and that array is—the first one is the city, London, and the second one is the date. And then very efficiently, I can query all temperatures in London between date A and date B without having to use indexes, without having to use any table scans or anything like that.

So it's very efficient. So you can combine these different models together. Importantly, there's always a use case for a time series database. There's always a use case for a graph database as well. So graph thinks about data usually in a different way. You usually think about data in terms of metadata, which describes objects, and then you filter based on that metadata. In SurrealDB, we still have collections or tables. So you could create one big object table if you wanted to, and just filter and describe data based on the fields in that table.

But it's not really the way that you would come to SurrealDB and do that. And time series as well. Usually time series databases are specialists in evicting data and the granularity of data as you go on in time if you don't need that data for your dashboards or anything like that. So there are different requirements, but a lot of organizations are working on analysis over time-based data with graph, with document. And actually, if you're doing that with 3 or 4 different database backends, that can become incredibly complicated.

The performance can degrade over time as well, or just be harder to reach because you're working with different platforms. And that's where SurrealDB shines.

Yeah. So for us, we know that in certain areas, in certain models, we can actually beat the competition out there, even whilst having all these different models in our platform. As I say, some of the functionality of what you might see in a time-series database or a graph database might not necessarily be there, and it's not really a priority of SurrealDB to do that. But in terms of performance, that's definitely a key part of what SurrealDB is aiming to achieve.

In addition to that, if you're then consolidating different databases together and you're comparing that to a traditional backend which has multiple platforms, then definitely, the aim is to be quicker. Having said that, there are always going to be scenarios where another database might make sense. If you're dealing with graph data that all sits inside memory and it's being stored in a graph data structure, then that's always going to be quicker on a graph database that is sitting on a single node.

For SurrealDB, everything that we build has to work in an embedded environment, a single-node environment, so a single server. But then we have the ability to scale up. So if you need to have more writes, more reads, you can scale up the compute, you can scale up the storage. So we have that ability as well, which is not necessarily true of other databases, or scaling is sometimes a difficulty with other databases.

It's always a hard one. As a database, it's always a contentious issue, isn't it? As a database, you've got to put out performance benchmarks, and we're working on those internally. We're going to be publishing them soon. But you've got to compare yourself with, in our case, many different database platforms. So people want to know how we compare with the relational databases, the graph databases, how we compare with databases at scale, how we compare with databases that are embedded. Because it's so flexible, you've got to be able to compare yourself with so many different types.

And then also you've got to test yourself in the right way, benchmark yourself in the right way. So for us, it's about supporting many of the open-source benchmarks that are already out there and building our results into those frameworks, but also comparing ourselves with other databases in the right way. The benchmark game in the database world is a matter of fine-tuning and perfecting what works for you and how it presents well for you. But I don't think that's right. SurrealDB is about simplifying developers' lives, simplifying organisations' lives, and making it better and quicker to get to the end goal of building your application or building the platform that you need.

And to do that, it needs to be representative of many of the different environments, or as many as possible of the different environments that people are going to be running it in.

Yeah. So if you take everything I've said about consolidation and you then look at the world of AI and machine learning pipelines, it gets even more complex and confusing, as it were. For us, when you're working with machine learning models or artificial intelligence, whichever way you look at it, you're dealing with data, and your data is residing in a database. So for us, one of the pieces of functionality we have in SurrealDB is the ability to bring a model right inside the database so that you can run that model.

It's a custom-trained model or an off-the-shelf model. You can run that model right alongside your data if you want to run it on all the records in a table. Let's say you want to update the predicted house price of all the houses in a table. You can run it very efficiently. You don't have to push that data out into Kubernetes clusters through different platforms, wait for asynchronous events to come back. And having finished, you can just push that model into the database and have it reside next to the data.

So you're not having to deal with a lot of the administrative overhead of dealing with microservices and Kubernetes clusters and containers and everything like that. And it comes back to the question you asked earlier, which is: why rebundle? Everyone built microservice-based architectures because that was the easiest thing to do. It meant that you could keep components of your code small and you could build up your application from there. But it also led to a large, massive amount of complexity. And ultimately, it all comes back to the data.

If you look at the biggest organisations in the world, they're leveraging that data in better and bigger ways. And for SurrealDB, for us, we want to make it easier to work with, to query, to learn from your data. So being able to do that in a single place without having to think about the infrastructure around that is really what we're trying to do.

Exactly. And underneath the hood, this is still powered by GPUs. It's still pushing through to the same technology that traditional models or models out in other platforms are still running, but it enables you to bring that closer to the data. So you don't have to think about the infrastructure around running that processing or understanding the models against your data. You're just having to think about how does the model work, what is it giving me, what is it resulting in, and then how do I run that on my data?

I think cost definitely comes into it, but I don't think it's the main reason why people are turning to SurrealDB. I think longer term, people see the gains of being able to consolidate different databases. But especially if you look at the large organizations using us, they're not coming to us and saying, "I'm going to replace four different databases that I've spent the last 10 years implementing." It's usually being able to solve one problem to begin with. And that problem is usually that they're having to work with many different data types, or they're not able to work with the data types that they want to, or not able to query in an efficient way.

And so they start using SurrealDB, and then they can see the benefit of bringing more data types and more models and more ways of querying to SurrealDB over time. That's definitely what we're seeing. We're seeing use cases from real-time analytics. So the combination of document and graph to bring kind of expected query times to things that need to happen in real time, as it were. We're seeing use cases where it's purely being used as a key-value store the majority of the time, but then they want to expand upon that and have filtering and document data storage.

So it really is about being able to bring those models together. And I think in the long run, that does reduce costs, it does reduce development time, and it reduces the complexity of people's infrastructure.

Yeah.

Exactly. So, e-commerce website, graph to analyze the related connectivity of that data. And specifically, it's product recommendation. So being able to detect in real time, not based on analytics of yesterday's data, but actually in real time on the events that are happening on the website right now, how do we analyze which products to recommend to this user based on the behaviors of other users, based on the behavior of this user, and based on many other attributes. So being able to combine graph with the document—the document is what stores the actual data, the graph is what relates that data—and then being able to do that at scale.

And I think another key part of being able to scale out your database is that gives you the availability aspect. So being able to say, look, I can spin up 15 nodes or 10 nodes, but when three of them go down, my database is still up and running, as opposed to when one node goes down, I now have an issue. So that obviously comes with the ability to scale out your compute and scale up your storage.

Condensing one year of work into 30 minutes was hard enough. Let's condense it into one minute. One of the reasons that people love working with SurrealDB is the query language. It's SQL-like, so it makes sense to people who are coming from a relational database, but it brings these concepts of graph and key-value into it. For us, extending and building upon that language is important. So, we've built in new functionality that enables people to work in a more programmatic way.

In addition to that, security and stability. We're built in Rust, but being able to ensure that users authenticate to the database correctly. One feature we haven't spoken about is being able to lock down your database. So, being able to say, look, certain users can only see these records, or they can only run these functions, or they can only see these particular fields. One of the other features we just released in beta is GraphQL support. So, being able to query your database.

This is not a middleware layer that sits in front. This is built right into the database. When you define your tables and you add your data to the tables and you define fields on that data as well, your GraphQL is automatically generated. You can configure how it is output, but it's automatically generated and you can query that immediately. So there are a lot of organizations out there running and building on GraphQL. And so that now is an instant kind of configuration flag when you get going with your database.

So, temporal querying. We've gone full circle. This is how it started in 2015.

But actually implementing this in a way that's scalable and performant is just really hard. We will be the first database that enables you to time travel in your data in the different types of models that you can work with in SurrealDB. So now, when you're using the embedded storage engine called SurrealKV, you can add a version clause at the end of your SELECT query or INSERT query, and you can actually time travel back, which isn't that big a thing. You can do this in some other databases, and you can do it if you have a time column and you filter on that time column.

The difference is in SurrealDB, you can take your document database or document data that relates to other data through graph edges. And you can also take your time series data and you can go back in time. So you could say, I want to find all products that this person has purchased, and I want to find other people who have purchased that product and what products they purchased. So that's the graph. And I want to do that as of now. But it's now come up to December, and I want to know for the holiday season what products to recommend based on last year's activity.

Now I can time travel back in time a year, see what the data looked like a year ago, and effectively, immediately, I'm able to look at that data, look at how the entirety of my database—from graph, from document, from key-value, from time series—looked at a particular point in time.

Absolutely.

Yeah, so we wanted to make it a Surreal experience, right? So effectively, there's not really much difference. You can run Surreal locally on your own laptops, in your own clouds, or you can run it in the cloud. And that experience is supposed to be very similar. It's supposed to be simple, quick to get going with. The difference in Surreal Cloud is that it's all supposed to be super easy. But in addition to that, we don't just separate storage from compute.

We're actually going a step further than that, and we're separating storage from compute. So how this works is, we have a storage engine running in the cloud for all of the clusters that are spun up by users. We then connect our compute loads to that, but the data itself is actually residing in object storage, so S3 in an AWS situation, and that gives us nine nines of durability on the data that resides there. It enables us to scale out as well.

And at the same time, the storage layer in front is acting as a cache. So you get the same performance that you'd have in SurrealDB traditionally. You're able to query in the same way transactionally. So everything that you write to the database, when it's written and confirmed, every other reader sees that data. But then you're safe in the knowledge that your data is residing on S3. And if your instances go down, then they can be brought up again as well.

And this is really important in analytical use cases. So being able to spin up large clusters that read large amounts of data, and then when you don't need those clusters, if you want to scale them down, that can now be possible. And also what we'd be working towards is the ability to autoscale up and down based on the needs of your application.

I just want to start by saying, look, I love data, I love databases.

We're all friends. I wouldn't be here if I hadn't had all of those experiences and those learnings on the different databases that I was running. And obviously, there are some great companies out there pushing incredible technology. I think if you're looking specifically at SurrealDB, the reason we are able to have so much interest from developers and engineers is because we're not doing things in the same way that it's been done before. We're not building on top of Postgres and therefore limited by what Postgres has to offer.

We were able to build out our core infrastructure and the core engine of SurrealDB, and that gives us additional benefits down the line. It enables us to support different models, it enables us to scale or run embedded, it enables us to run in so many different ways. There's a reason that SurrealDB has seen so much interest from users and massive organizations around the world, and that is because there is a gap in what the database market is offering. A lot of people, as I said at the very beginning, a lot of organizations are focused on improving the performance of an analytical database or reducing the cost of an analytical database or adding some functionality to an alternative product that's out there already, or offering a cloud version of an open-source product.

But no one's really come along and said, how can we completely reimagine this and take concepts of SQL, but not fully lift SQL from the standards? Take concepts of graph, but not be a graph database. Take concepts of time series, but not be a time series database. And we're looking at it from the point of view of how do we really help developers and organizations improve their developer experience, improve their application build times, their application development times, and improve the management process once launched.

Rather than looking at milliseconds or nanoseconds or cost. And that's, as I say, the database world is incredible. There's incredible products out there, but there's a reason that SurrealDB has seen so much interest.

I think there are learnings as a business, as you present yourself externally, and there are learnings internally as well. One of the hardest things for me—I built this code in the very beginning. I spent seven years on it, and bringing people into that codebase is tough. Still to this day, I'm overseeing a lot of what is going into the core engine. And bit by bit, that's reducing. But it's almost like giving a baby away. As a highly technical product, like a database, specifically like SurrealDB, the outside world can love you and hate you at the same time.

They can love what you're building, but at the same time, they expect you to be where a 20-year-old database is in terms of functionality or performance. And I think sometimes people forget that this is an incredibly complex product to build, and it takes time as well. And so, one of the challenges is: how do you focus on engineering? You have to devote time and resources and engineering talent to building this incredibly complex source code and an incredibly complex product whilst, at the same time, catering to the community and their needs and what they want and what they want to see, even if that might potentially slow down what you're building.

So it's a balance. It's definitely a fun journey.

We have had the benefit of being able to hire from the community, where you can already, up front, see the quality and the passion of people before you bring them into your organization. And at the same time, SurrealDB came about because I was able to spend time thinking about how to change a particular market, not by building according to a specification. And so the engineers that we have and we want to have in SurrealDB need to also have that imagination and that freedom to create, because I think it's through that freedom that you get amazing ideas, features, and functionality.

And I think it's apparent that organizations, users, and developers love what we're building. But it's important that we keep having that flexibility in the engineering team in order to let the engineers work on really what they're passionate about, in order to deliver, longer term, what we want to deliver.

I mean, you've met my brother. For anybody who has met my brother, we are very different. No one would actually guess that we are related at all. He is non-technical, as it were. He can build websites and code. He does code our website, but he is non-technical. His expertise, his passion, lies in the branding, the design, the external perception, the external imagery of the business. Anyone would say that normally wouldn't work, but I think there are two things.

First of all, we have the technological understanding and the branding understanding. And I think that's quite rare, especially at an early stage, for founders to have. The other thing is we have trust. I absolutely trust—not necessarily trust about what my brother's going to do, but trust that we have the same vision, and trust that we have the same understanding of where we want to go and how we want to do it. And that makes running your business easier if you don't have to constantly be thinking about your co-founders and everything else beyond that.

Because a lot of time goes into engineering and building the organisation and talking to users and organisations who are using us. And there's not much time to worry about the politics of it. And I don't know the statistic; you're probably better than me on this, but a lot of startups fail because of the falling out of founders. I'm not sure what that number is, but it's high. And so having that trust and having the mutual understanding of where you're going just makes it so much easier.

Twenty years ago, it would have been a fight where I would have lost, and then that would have been the conflict resolution. I think we're often on the same page, to be honest. He doesn't direct the direction of the product or have any influence over the direction of the product because that is my knowledge. But vice versa, I don't direct—or have any influence over—the direction of the brand or the marketing side. That is where his passion lies and where his expertise lies.

And so there's no crossover in those areas. But I think also it's important to note in any organisation, but also importantly in a startup as well, you can't just focus on the brand or you can't just focus on the tech. You have to focus on both. For SurrealDB to be successful, we have to be an incredible technological product, and we have to have a good brand to go with it. We're talking to large organisations, and the brand and the business matter as much as the technology.

And you talk to developers and engineers who are working on side projects, the technology matters more than the brand, but you have to balance both of those out if you want to build the company that we want to build.

Awesome. Yeah, I've got some exciting stuff ahead. So thank you for having me, and great first podcast.