Excellent Open Source User Experiences With Karthik Ranganathan  ## Metadata - Author: [[The Business of Open Source]] - Full Title: Excellent Open Source User Experiences With Karthik Ranganathan - Category: #podcasts - URL: https://share.snipd.com/episode/c42e8edd-a27a-495e-985c-23a49bb8da72 ## Document Notes ## Highlights - **Why Open Source Databases Win** - Choosing a database is about forming intuition on what to prioritize for your workload, not just listing features. - Open source databases gain trust through transparency, longevity, and flexibility, which proprietary ones lack. Transcript: Speaker 2 So let's dive into the question of open source and business, et cetera. But the first question I wanted to sort of jump off with is why does everyone want an open source database? Like I hear very infrequently of a new closed source database, maybe just because of the space I'm in, But it doesn't seem like there's many, many oracles out there popping up. Why is it so important in the database market to be open source? Speaker 1 Yeah, I think this is a very great question. So this actually goes down to a little bit of the thesis that we had when starting our like, you go by the company. And maybe I'll use a little bit of that and then branch into why open source has become important. So when we started, as you know, we had built Apache Cassandra, saw its uptick. We'd done HBase, saw its uptick. MongoDB was formed around the same time we saw its uptick. Any database that's a new database, whether it's a relational database, like an NCCQL compliant new database or a NoSQL database, takes about six to eight years to really penetrate And get into the vernacular for people to understand what they can expect from it, right? So that kind of changes things. Like if you think about it from that perspective, every time a new database comes on, it'll take people six to eight years to understand what it does, what it doesn't do, where it goes, And quite simply to have intuition for, ah, I have this type of a workload, that's the type of database I need. So it's about forming that intuition. People don't think about all the features of a database when they need to use it. They think about the intuition that it forms behind, right? It's kind of like it evokes, okay, this type of a pattern, that's the right database. Now, every time a new database gets introduced, it lives for a while, and a proprietary database has a lot of risk behind its longevity, right? It's tied to the company that's putting the database out, and what happens if the company doesn't do well? What happens if the market changes and the company changes direction dramatically and things change a lot? It breaks that mental intuition model or a new database product comes up and it's another six to eight year cycle, right? Now it's okay if you're just adding this on to your arsenal of existing core databases. But it's not OK if that is your core database. So when the thing flips around to something like longevity, it becomes super critical firstly to show that this is around to stay. Second piece of the puzzle is around transparency on where this is headed. So for the first perspective, if you look at databases that have been around a long time, Oracle, SQL Server, MySQL, Postgres, DB2, Informix, these are pretty big databases, pretty Well known. But even in this list, right, as the hardware and the infrastructure, everything changed, things like DB2 that are running on mainframes became very difficult to run in a cloud -native Environment. So DB2 is not as often opted for newer applications as some of the other databases in this list. So if you start working down this path, you want ultimate flexibility and ultimate freedom because who knows, like we have cloud now. We used to have VMs before. We have containers now. We used to have bare metal. All of these exist today. You want the ultimate freedom and flexibility. And an open source database gives you the transparency of where it's headed, what it's doing, and also allows you to influence the direction from an industry standpoint, not necessarily Just a vendor standpoint, because sometimes you don't know what the vendor is thinking behind you, kind of look at their roadmap, but you don't really know where it's going in five years Or ten years. Ten years, the roadmap is just a couple of years out. So putting it all in a box for transactional systems, it's very difficult to try a plus one product, right? For example, you have a billing system, or you have an order system, or an e -commerce has a shopping cart. You can't put another database on the side and try it alongside your original. There's only one database that can power the shopping cart, or your billing, or your login systems. And that database has to have longevity and transparency, right? And all of this makes open source kind of table stakes. ([Time 0:02:01](https://share.snipd.com/snip/d72a229a-0a62-4f42-8481-64e52f94deea)) - **Deployment as a Spectrum** - Yugabyte offers a spectrum from fully managed to self-managed deployments to meet diverse customer needs. - Customers often utilize all options depending on application priorities and security requirements. Transcript: Speaker 2 I'm really actually interested because you have it sort of presented as like a scale, the simplicity versus scale. And I think that that's a really interesting way to present this. And the thing I was bringing up was I think last time we talked, you had been moving away from focusing on self -managed to focusing more on the fully managed, but you also have an intermediate Option of co -managed. Would you say that all three of these options are sort of equally important? Um, and how, how did you land on, on these three? Speaker 1 No, I think that, yeah, this, the, the, they're each different in the way they came in. So maybe I'll start with the first things first. So when, again, we were a 2016 company, so relatively recent, right, in terms of the cloud journey and when it started. So the two bets, the two key bets that we did when starting the project, when starting the company, all of it was that, you know, Postgres and the relational cloud native database is going To become super critical in the future as we modernize existing applications and continue to build more applications. So that was one. And the second one was the value capture for it in terms of a commercial business would be around how do you run this efficiently. That's going to be the most important thing. Right. Now, we kind of had our theories on how it would play out, but I think it's interesting actually to see how it played out, which is if you look at Postgres, it gives you the theoretical freedom Of you can go to any public cloud or private cloud and run it. Now, let's say you go to Amazon and you run it in Amazon, you pick their managed Postgres service, which is RDS. Or, you know, if you need a little more durability, you go towards it, or you have a couple of options there. If you go, if you said, no, I need to do the same thing on Google Cloud, you pick a couple of equivalents there, and Azure, you do something else, and on -prem, but you don't really have an Equivalent, so you'd go and do the best you can with what you get. Now, the problem in all of this is, the Postgres is the same, but it's a lot of work going from the Postgres that's the same your application running on this managed service that has the Equal instead of properties. So that's a pretty big jump in reality. Because when you think about what it takes, it takes monitoring, alerting, encryption, security, key rotations, how do you make the actual connections, whitelisting clients, network And machine types, and storage. And I could keep going. There's like 50 to 100 things that become important. Now, if everything was like, OK, here are the 50 things that are important, and you make these choices in Cloud One, and those choices in Cloud Two, and they all work the same, that would Be great. But that's not how it works either. So the choices are overlapped. They're not exact equivalents. There's gotchas. There's like, oh, you do it this way here, but you do it a different way there. If you chose this thing here, you'd be fine. It won't really fail if worst comes to worst. But that thing there will really fail, so you need to go to the next option instead. So there's all of these, this type of what used to be knowledge that gets built. And when you go from one like type of infrastructure environment to another, the tribal knowledge does not translate. It cannot translate. And then it has to be built again the hard way around by failing, right? And so the value capture that we bring is we codify this tribal knowledge into actual DevOps code and expose it as APIs and say, you configure the system, but we'll give you the equivalence And we'll mask this kind of, you know, things that happen, including the type of failures that you can get exposed to all of that stuff, right? So that was the genesis. We wanted to do this as a fully managed, where we exposed an endpoint, but we quickly found out that, you know, the people, like most of the enterprises are not willing to give up their Data to a third party, they still want full control. And rightfully so, because it's so critical. So at that point, we said, you know, we're going to make the managed service also ship into the customer's environment, and they can run it themselves, and we can run it for them and expose An endpoint and those were the two models, the two commercial models at the extreme. But there's always even more flexibility that's needed. They want to go across multiple clouds. They want to do other things like this is back then. And so when it comes to real flexibility beyond that, that's when we would push them towards the open side or we would ask them to use the management plane, but use it in a lowest common Denominator fashion where they do some of the infrastructure automation depending on what they wanted, right? Because there's only so much that we can also build in order to accommodate. So if the pattern is relatively common and something that can be extended based on what we have, great. Otherwise, open source is always there as a catch -all and they can build their own DevOps around it. Right. Now, the interesting model we started seeing is that there are certain types of infrastructure. And so this is great, but the self -managed model still means that the customer has to do work. They have to hire people. They have to run it themselves, even though it's very easy and we're here to support them. They didn't wanna do that. They're like, there's a lot of routine tasks, like how do you upgrade the software? Or how do you do nightly backups? Or how do you know that the key needs to be rotated and just get it done? Or just stuff like that, just regular stuff that they don't wanna do, right? And rightfully so, why hire a person for this is boring. And it's better done by people like us who know which version to upgrade to, what is better, all of this stuff we can just take care of. But what is the problem for us? It is the complexity of the customer environment. Like, oh, you cannot get into this machine unless you actually use your thumbprint because that's the security policy in their company. That makes it very difficult to do much, right? Or, you know, or so on and so forth. Like you cannot use this port, you cannot do that. So, and these are there for reasons, but this also makes the ability to manage and the ability to work inside the customer environment very difficult for a vendor like us that can actually Give them value. So that was the blocker. What we discovered is there are certain types of that are becoming very common, like the virtual machines on the three big public clubs, AWS, GCP, Azure. Kubernetes is a great kind of independent medium which abstracts out the hardware and gives us some APIs on top. So there's more and more of these types of patterns starting to emerge. And what we found is that we can actually work with the customer to have them, we call this BYOC, bring your own cloud. They can bring their cloud, but it's a cloud. We know the rules of how to play in that cloud, and we can kind of talk to the customer to say, here, these are the things we need, and this is the stuff we can do for you. And if you give us this few other things, we can do some other things for you. How do you want to go about it? And what is your security policy? And we can match it and kind of figure out the value, right? So we added that. ([Time 0:13:32](https://share.snipd.com/snip/829eb382-7dc5-489d-a182-ab7fd7f1b24a)) - **Same Core Database Across Options** - The database engine is identical between open source and managed service to avoid holding users hostage. - Managed services provide operational ease without accessing or viewing customer data. Transcript: Speaker 1 The database is the same. So that's actually one of the guiding mantras for us, is that we don't want to hold back value because that's just another way of irrespective of whether our management plan can address The customer's need or not, we're going to hold them hostage in order to pay. And the second thing is maybe a customer gets so big that they actually are better off investing their own team. We hope it won't come because that's what we're building towards, but maybe that does make sense for that particular customer. And so for us as a company, we take a longer term view on these things, which is, you know, it's great. If that's not the right fit, what we're offering as services is not the right fit for the customer, but the database is great. And perhaps there's a different application at a different point in time in the future when this would become valuable to them and they would come to us. Ultimately, it comes from our belief that the value we're putting out in terms of how easy it is to operationalize and manage and use across a variety of different infrastructures really Makes it brain dead. But you know, there are cases, everything is built for a set of cases and there are a set of exception cases that, you know, we would not address. And we don't want to prevent people from doing that. So the split has been very intentional. The split is also intentional from the point of view that the management services do not connect into the database. Like what I'm trying to say is the machines, and the disks, and the network connections, and the backup, and all of that is something that the managed services would do. But the managed services do not connect into the database to create tables or read data out of the database, right? So that keeps also a separation in terms of the security and privacy concerns of, you know, what can we do when we're fully managing it? Well, we cannot peer into the data. The data is encrypted. The data is something you can touch. And that's fully controlled by the developer while we're helping the operator and the architect get around all of this stuff with great ease. ([Time 0:21:35](https://share.snipd.com/snip/236d2a36-6d8e-4542-a35c-f99e6f4c5eb6)) - **Evolving Role of Open Source** - Open source use has become a primary marketing tool and risk mitigator for Yugabyte. - The increase in downloads and engagements reflects customers wanting to try before engaging. Transcript: Speaker 1 It has, I would say it definitely has. I think, I mean, open source is, I think ultimately it serves a few different functions for us. Um, and I'd say that while the, the list of this hasn't changed, the distribution or the importance of these has definitely changed, right? So it's more, I'll put it from that point of view. It is a great marketing tool. So in the sense, developers can try it out and see if it's valuable to them ahead of time. That still remains the same. We have a lot of developers trying it out. It's something that de -risks the enterprise, like we talked about. So if either, if they want to know where we are headed as a company, or look at the roadmap of Postgres, that's where we're headed. They're extra things, but we're not taking away from Postgres. So that's still the same. And de -risk from what happens if this gets too expensive? I don't want to be like, you know, Oracle is pretty famous right now all over for being too expensive. And, you know are like, oh my God, there's an audit coming and this and that. So this is like, if it gets really that expensive and the people running it can think they can do better, great. They should be able to have that option, right? Even though it keeps us in check too for the value that we're providing, because the development of technology is accelerating. And 30 years ago, the rate at which technology would progress, the rate at which the industry would move, is far slower than the pace at which it moves today. So perhaps what we're doing now can be extremely valuable, but in 10 years from now, that can be table stakes, and we have to build on top of that, and that's kind of the promise that we do. So that's the second form of de -risking. I'd say the other things that it does for us as open source is people trying out and contributing to it and people trying out and testing it. So it's the roadmap and the direction and where the industry is pulling us. And we get to hear from a variety of people. We get to see use cases we never thought were, they're, oh my God, that's a really crazy use case. And then we get to see more of it. And maybe it's not that crazy. We're the ones who didn't think about it and so on. So we get that creatively. So we see all of that. All of it has amplified. But one thing we're seeing more of is people just trying the product for some of their use cases ahead of time. And then talking to us, this has just exploded a lot to the point where there's so many downloads, there's so many deployments that we barely able to keep track of it. ([Time 0:23:48](https://share.snipd.com/snip/bb66901e-3e0c-4742-9cf0-e83e15c635e5)) - **Enhance Open Source UX** - Invest in improving open source install and user experience to drive adoption. - Simplify complex concepts in your product to help users understand value quickly. Transcript: Speaker 1 I think we're pleasantly surprised to a large part is the honest truth, but there are things we did. So it's not, I mean, yeah. So I mean, in other words, it's unclear if what I'm going to say is the reason why all that happened, is the only reason why all that happened, or if there was a, you know, like just the right Timing and the product that worked out, I'm sure there's a large part of that as well. But some of the things we did were to invest pretty heavily in our open source, you know, install and user experience. It's more us getting out of our own way more like, because, you know, we, was to, you know, five seconds, five minutes, and five seconds to install, five minutes to aha. So we invested quite heavily in that. So it makes it brain dead to install and just get started. And a lot of the defaults that we looked at were to make sure people just had a good experience out of the box and understood what was going on. So that was one big part of it. I think the second big part of it was we are a distributed relational database, right? So people get the relational database part, people get the distributed database part, but people often struggle with the distributed relational database part, how they both join Together. So we invested in a number of experience type work. So this is not just about install experience and getting started. This is about actually visualizing those components and making sure that we're able to, even though not to great depth to some level, to some degree of simplicity, it's a balance. Explain what is relational and what is distributed, how are they coming together in the product, not using words, but using activities that they do. How do you experience, for example, scaling this, or how do you experience when a node fails, what happens? We'll make it all very simple in the product. So those are things that we actually did quite a bit of. Of course, our usual evangelism that we've been doing, so it kind of accrues over time and gives you an experiential growth over time. So that's another aspect that probably is kicking in. But most of all, I believe that we're finally getting to a spot where people are unlocking cloud native services and the power of the cloud and the cloud native architectures. So there's a huge portion of that as well, right? So the more Postgres we become and the more cloud native we become, the more easier it is for people to realize this value. ([Time 0:29:33](https://share.snipd.com/snip/34803b4f-90a4-4ee5-b8c0-67f672cd4e20)) - **Early Start Pays Off** - Yugabyte started slightly early in 2016 when cloud adoption was still nascent. - Their timing allowed building a solid product as industry shifted more seriously to cloud-native in 2021. Transcript: Speaker 2 Or did you feel like you were pretty well timed for the market, for the adoption of cloud native in general? Speaker 1 I think we were a bit early to be honest, but I mean there's a bad twit, but there's a good twit as well. So this is roughly the journey. By the way, this is also a very, very insightful question, so thank you for that. So in 2016, we started, you know, the company. And 2016, 17, and a good portion of 18. We obviously talked to a lot of customers all through, like, you know, hundreds of customers each year. And if I would categorize the different eras in the history of Yugobai, so 2016, 17, and a good portion of 18, most of the enterprises, most of them were considering if cloud should be On the roadmap. So it was not like this is the cloud and this is what I'm thinking. It's like, I don't even know if I should think about the cloud. Let me think about that first. So that was the state. A lot of it was on private clouds. Of course, the bet that we had was it's going to go to the public cloud. If that didn't work out, well, good luck to us. We wouldn't have been here. So that was the one. And then I'd say the latter part of 2018, 2019, and even 20 to a good portion, was people lift shift into the cloud. So it's like, I have a Postgres or an Oracle on prem. I want to go to the cloud. I want to now put Postgres or Oracle in the cloud. That's it. There's no room for you to buy a DB in such a thing, because we actually help people embrace and enhance the value of the cloud, which is commodity hardware, makes it cheaper, but gives You the ability to scale on demand and flex or multiple different data centers so you can move your data all over the place. So these are the things we bring forth, but that's, but if you're on an Oracle or Postgres and you move it to an Oracle or Postgres in the cloud world, there's not much we can do, right? Because that's the pattern that users were looking at. And I think it was around late 2020, 2021 that I feel there was slight shift in the industry. It was still early, but that was the shift where we saw people starting to actually think, oh, wait a minute. If I moved my Postgres or Oracle from on -prem to cloud, I'm actually getting the worst of all the world. It's more expensive. It's less reliable. And it's more like noisy neighbor and all of this stuff. And it's just a heck of a lot more inconvenient and so like people started thinking about those problems at that time and there was still like I think 2020 -21 the issue of you know like Let me use encryption but let me also lock the door that kind of a thing where you know they put all the on -premise security techniques and the cloud security techniques and every other Security technique and just make it ultra secure. But it was so secure, no one could get in, like even their own developers. It became really tough to work. So there was a funny period in the industry at that point. But around 21, it switched, right? And then we're seeing more and more and more people adopt. And I think it's accelerating now. This is a great time, right? But the good part in all of this for us was the fact that it takes us a while to build a database. It's not quick. So database is slow brew and, you know, it gave us the time and the runway and the ability to see where the, you know, industry is headed and, you know, build the right type of product with Engineering because in a transactional database, we simply cannot lose data. That's non -negotiable, stability is non -negotiable. So it helped us get all of that right. And it also helped our bet play out for longer because we were the first to say Postgres as a distributed database. And that did give us the advantage of being around for a long time and everybody recognized us as a brand and so on doing this. ([Time 0:32:00](https://share.snipd.com/snip/c2d77776-f822-4d65-9e5d-ccbc1a8f224a)) - **Hybrid, Multi-Cloud, and Edge Rise** - Public cloud dominance is no longer guaranteed; hybrid and multi-cloud strategies are rising. - Edge computing and repatriation to private cloud are growing trends reshaping infrastructure. Transcript: Speaker 2 In the past three years, if anything. Speaker 1 Yeah, no, no, there's a few. There's a few. So in the, let me see. So in the past three years, like I'd say three years ago, I would have probably told you that the move is predominantly to public clouds and that's the direction. Everything's going from private to public and it's going to take time, but that's the way it's going. I'm not so sure about that now. I see things come back also from the public to private because for certain type of workloads at certain you're better off doing it. It's kind of like public clouds are in, you know, depending on the, there's a lot of variables here but I'm just oversimplifying but to give an analogy, do you want to rent a house or do You want to buy a house, right? Depending on the workload and the details, you might want to go to a public or not go to a public. So that's one that I see is something that I feel is going to happen for the next decade, if anything is going to intensify. The rise of edge, which I was like, yeah, it's there, but it's there for niche workloads, but I don't feel it's that niche anymore. The edge is the thing that's really waiting to happen. I hear more and more about it. But the rise of the edge and what I call repatriation into private cloud, those two are real. They're working together to kind of equalize how much important it is to be hybrid. The second thing I'd say is I was... This was more of a theory back then, but now I'm convinced it's real is the importance of multi -cloud strategies for enterprises. Like, you know, back then it's like, you know, the number of people that would say, you know, so what, we're just like decided on AWS or G1, these clouds, and we're going all in. And, you know, it's probably better for us and that's okay. But, you know, when the acquisition happens or when something else happens, there's a variety of things that happen that force people to go into multiple different geographic locations, A presence where one cloud is strong, a service that one cloud specializes in. All of this has just changed the dynamic because the clouds are competing with each other too, right? So, like if there's a, for example, an analytic service somebody might want to go to Google. If an enterprise application, they might want to go somewhere else, or like to maybe to Azure, or if there's like some other type of modern cloud native application, they might want To go to AWS. And so the presence in multiple clouds is real. So that also, I can tell you confirmed that that is real. And edge and off -prem Off -cloud is giving rise to Kubernetes also becoming important. So these things, Kubernetes, not quite something I had changed my mind about. I always felt it was there, it's still there, but not quite in the way I thought about it. But nevertheless, that still remains, right? So I'd say all of that, yeah, I'd say those are the main things. The thing that was tough to foresee was the Gen AI movement. That's pretty huge. So that was a surprise more, not like change the mind, but more like, oh, wow, okay, this is a huge title wave. Yeah, that's about it actually, I'd say. ([Time 0:35:52](https://share.snipd.com/snip/ad54fda1-0da2-465c-bef5-98eb61616fec)) - **Learning From Managed Service Mistakes** - Early users overloaded their clusters beyond capacity causing failures that seemed like database instability. - Yugabyte shifted roadmap to improve user experience, adding protective measures and clearer guidance for users. Transcript: Speaker 2 What in past three years, since that's the time since we last spoke, has been your most interesting mistake? Speaker 1 I would say it's the biggest mistake I would say is that we are a product that is cloud -native, in terms of the database, and we are cloud native in terms of our orchestration layer and Our management layer. We're cloud native through and through, right? And so we assumed that, you know, we have everything that's in the cloud native stack, and we go put it in the public cloud. So like, again, genealogy -wise, we talked to all the customers, and we had the self -managed product first, because that's where the demand was in the market. And we invested in building our fully managed cloud in 2021. That's when we started, because it required, you know, in addition to all this, you need SREs, you need other things, right? So it's kind of a, it's a business case to be made. And that's the, it was, it's a question of time. And when we wanted to open out that, that aspect of the company and the business. So we invested in that. And our assumption, our calculation was that like, you know, we have every layer the cloud native stack ready to go. And you know, this is going to be pretty quick for us to get going, right. And and believe me, it was we actually got our we started building in February. And we actually released the product in September, October. So an incredible speed with which we were able to build because of all of this. But the mistake was that we assumed that that would be the cloud we wanted, and we're good to go. But what we realized in talking to a lot of customers and what we were doing after was that the buying pattern in the cloud or the usage pattern in the cloud is that people don't want to talk To us, don't want to read and don't want to even think about what you're supposed to do. It should just work. So simple things like, for example, let's say that they created a small cluster and the cluster is capable of doing, let's say, 1,000 operations per second. I'm just making these up. Now, the person needs 1,000 operations second and they come in or the person may need say they don't know that it's thousand, no one's reading anything, right? They say, okay great, let me create a small cluster, I did it and I want to run this workload, let me go run this workload and the workload happens to be 10,000 operations a second, so 10 Times what the cluster is created for and they unleash it on the cluster and naturally things fall apart and the cluster fails. And their first reaction is actually quite interesting. We did this as the early beta usage user experience thing. It's like, I thought you were a highly available database. What happened? It's not working anymore. And we're like, no, that's not how it works. I mean, you got it. So, and then after three or four of those were like, you know what, we're a highly available database. We got to, you know, even if they do 10,000 operations, we got to say no to 9,000 and say you're under subscribed or you're over subscribed, you need to scale up and we'll just do the 1 ,000. So, that was one or there's just all these crazy kind of things, right? Like even if they wanted to do 1,000 operations a second and they have like, for example, a hundred gigs of data, a hundred gigabytes of data they have to load, no one's thinking 1000 operations Per second while I load this data. They're thinking 1000 operations per second after I load this data. Oh, I just tried to load all this data, which was 10,000 operating database data. Oh, wait a minute. Do I really want to run this database? It's not even working. I'm not even able to load the data, but it's all these things, like, and like 20 other small things, like we're a database that's built for availability. And if they find that a node fails, and, you know, they kind of saw that the node failed in the UI, and they're like, you guys never told me the node failed. I mean, how can I trust you to run a service? And we're here to tell them, no, no, but that's okay. It won't matter. It worry. And I'm like, oh, that's really awesome. So it's these small things that you don't expect. I see you can call it psychology or I don't know, behavioral, like things that, but that was a big mistake, I would say, like in the sense, we didn't see that coming. And we had to retrofit and we had to change our roadmap completely to say, you know what, let's stop all the other things. Let's kind of fix, even if it doesn't look like the right thing for us, it's the right thing expected of a service. So that's kind of also a part of the value capture, as we were talking about. So, but you know, it is things that are subtle. So I'd say that's a huge learning in managed service software versus managed service. Speaker 2 And what do you think allowed you to basically make the decision? It was something you had to address. Like at what point did you, were you able to say like, oh look, this is a big enough of an issue that we need to change our roadmap? Speaker 1 Yeah, so we saw a tremendous amount of interest. Like, you know, it's funny in building the cloud, we actually did something interesting. We had the whole managed service software. So we said like, we don't want to wait to build the cloud to learn the lessons. Let's accelerate it. So let's run an early access version of the cloud. And we told our users and customers, look, we'll have to migrate you off this thing eventually, but we're doing this because we can and we want to learn and we'll give you a discount for Doing it and all that other stuff. So we got 10 plus customers on the early access in the PDA that we built the actual service on the side. And a lot these customers' questions and behavior actually influenced how we built the cloud as well. So we actually saved a year to two years of learnings right there. But so we knew the demand was there. Now after the cloud, but we had to do all these things manually by hand. We had to do 20 things because it was the early days. And that's what the Early Access Cloud was supposed to be. It was learning while we're doing things by hand, and it's not supposed to scale. And when we opened it up, and then we said, okay, we got about 10, let's do the next 10 or 20 or 50, and we started going after those, we found the same patterns of complaints coming back. And so at some point, we're like, oh my God, we need to fix this thing right away. So we had to slow things down, we had to tell customers, look, we're taking a comprehensive look at this thing. We're going to go after, you know, usability and stability and performance as the customers view it or the users view it rather than the way we view it. Because it's not really, if you think about it, in the database level always, or it's not a thing that you would expect to fix in the database, but it's still something that the users expect. So we had to do that level set because we just saw a lot of demand and we got stuck in the same points. And then we had to do a lot of manual work, one way or the other, a lot of manual work to get around those situations. ([Time 0:39:03](https://share.snipd.com/snip/2c401118-7de8-4110-a762-07f0911ebf87)) - **Reduce User Friction and Automate** - Build usability features like browser-based shells to reduce initial friction for new users. - Automate operational tasks like scaling clusters before loading data for smoother user experience. Transcript: Speaker 1 And it was a tough time with things just coming in, the same things coming in at high velocity. And we'd be like, oh, what, there's just going to happen next. Okay, now there's going to happen next. And so it's all the small things that matter. Like, like, for example, can we increase the cluster size before they load data and then increase the velocity of data load? Because we can. It's very simple for us to do. It's much harder if we give the instructions to a user to do it, but we have the service. We can actually do it. Or the same thing with even trying things out. Like one of the big drop off points we noticed was, you know, people come to us and they set up the database and they are not able to figure out how to connect something to it. And they just need something. They just need a command prompt shell to try it out. Like a Postgres shell to try it out. And that is running on their laptop. And connecting this is like a lot of, you know, figuring out IP, white list, this, that. So we said, okay, fine, let's just build it into the browser and give them, you just want to test the database, do it right here, and then you can figure out connectivity afterwards. So it's all of these things where it helps so many people initially, and the demand kind of justified it. ([Time 0:45:36](https://share.snipd.com/snip/c663df75-a0f5-4fff-88a7-289a373f36f8))