 And here we go. Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining this DataVercity webinar moving from a relational model to NoSQL, sponsored today by CouchBase. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DataVercity. And if you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle of your screen for that feature. And as always, we will send a follow-up email within two business days, containing links to the slides, the recording of this session, and additional information requests throughout the webinar. Now let me introduce to you our speaker today, Andrew Oliver. Andrew is the Director of Product Marketing, Product Evangelism at CouchBase. He taught himself to code when he was just eight years old and by 20 he was a DBA because he was the last one who knew how to operate the database and HP UX boxes. Now he focuses on telling CouchBase's story to a technical audience. And with that, I will give the floor to Andrew to get today's webinar started. Hello and welcome. Thanks, Shannon. So today we're gonna talk about how you can run a relational database schema on a NoSQL database. We use CouchBase for example, but the advice is generally applicable minus that many NoSQL databases obviously don't support SQL. As mentioned, I'm Andy Oliver and you can find me on Twitter at atacoliver. You can also email me at andrew.oliver at couchbase.com if you have questions and anything you wanna follow up. I wanna keep this at a high level. We're gonna go over the methodology to migrate and run an RDBMS application. We'll get a taste for the technical issues and differences. However, I'm not gonna get mired in the details. So we're not gonna go down into some of the differences on how indexes are handled and what have you. Just suffice to say that there's some additional sort of technical details that can affect you when you start doing more of the optimization type tasks. So we'll look at NoSQL. We'll talk a little bit about CouchBase. I wanna look at some of our migration options and really why you choose the methodology we're covering today, specifically migrating without optimizing and then optimizing as needed. First, let's look at NoSQL. When all transactions were offline and people browsed or met in person to conduct any and all business, batching data and relatively low volume transactions were fine. These days, however, users look at hundreds of things before making a purchase and everything's online and mobile. Supply chains are monitored and managed in real time. Whereas my package, where did the problem occur and everything especially in manufacturing midst data. So volumes of both reads and writes are way up. So people turn to NoSQL databases to make that happen. However, the first generation of NoSQL databases didn't do joins, they didn't do SQL, they didn't do transactions. People basically put up with them because they had to to meet some of their scalability and performance requirements, but they did their real work offline on mainframes and RGMSs. Now with business changing more rapidly, uptime requirements reaching 100% and everything moving online, this architecture is even more relevant. Moreover, now you need to analyze in real time. There's no more time to ship data over to another system, do the ETL, do some processing and then do some analysis. Analytics generally must happen now. What is my situation today? Even if I'm doing some projections or whatever, I kind of want that to happen more real time these days. That's why NoSQL databases like Couchbase support SQL joins transactions. And in Couchbase's case, we even embed an MPP. If you're not familiar with an MPP, Teradata and then these are those things are MPP type databases. We're moving to an area to an era where NoSQL isn't just for your volume, but also for reliability and flexibility as well. The most popular kind of NoSQL database uses JSON documents to store and represent data. JSON is the JavaScript object notation. It embeds key value pairs in arrays. It can embed sub documents. It can represent numbers, strings and bullions. JSON is supported by nearly every major language and platform and library. It's the language of the modern services of modern services on the internet. Even if your database doesn't support JSON, your application and application services are likely speaking JSON. The document is most analogous to a row in an RDBMS. Different NoSQL databases have different storage paradigms, but Couchbase stores documents in a bucket. However, a bucket is more like a database instance than a table. A table is most analogous to a set of documents with the same type, which we generally concatenate as part of the ID. So I can essentially represent my RDBMS tables on the left as sets of documents on the right. And if you look, you can see what's going on. One thing to note though, is while RDBMS is generally enforced constraints, NoSQL databases support agility or schema on read, meaning I can add a field to a document or emit a field from a document. There are various reasons this is quote unquote better and better isn't quotes, but it does mean that any constraint enforcement moves the query or application way. Another thing that is different is that generally timestamps are either a string, array or number. Conversions are handled at the query level. We recommend using epoch the number style or UNIX time as it might be referred. Let's talk about Couchbase. Couchbase is a NoSQL database that supports transactions, SQL and full tech search. It is a memory first, shared nothing distributed architecture. What this means is that the default behavior is that you can read a right from any node, the right will be put in the memory and replicated to at least one node. It'll be written to disk later. This is configurable, but then your application moves on. Once we've got it in memory replicated at least another node, your application moves on. If any node goes down, your clients don't care. They can just connect to a different node. Data reliability is assured through replication. I wanna make sure everyone has a good taste of how SQL and JSON works. So I've kind of sprinkled SQL queries through the slides and on this one, they're just window dressing. On here, you see an insert statement creating, you see creating an index, you see a couple of deletes. We'll see plenty of selects throughout, but just to give you a little bit of a taste on what SQL and JSON might look like. Couchbase is one of the leading NoSQL databases. You can build the community version via GitHub. We also have a pro version and announced a cloud version which you can sign up for. Couchbase can run local, you can run it on your own cloud or multiple clouds. It's RackAware built on Kubernetes, all of that stuff. You can also sign up for a fully managed as a service offering. We're now gonna go into all the sort of system and infrastructure type stuff today because we're focusing more on the SQL, on NoSQL topic but suffice to say there's a lot of options there and it supports a modern multi-cloud cloud-based architecture as well as on-premise with most people's Kubernetes stacks. We're gonna focus on Couchbase server today but Couchbase has a mobile offering in a gateway that allows local peer-to-peer and client server edge applications. While we focus on mobile usage, building resilient applications is just as important for desktop and other types of applications as well. So whether it's a grocery store or a factory floor, if your connection with cloud or your data center is severed and you don't want your application to cease function even if it has to reduce capabilities, Couchbase has an offering that offers the same kinds of capabilities on a phone, desktop, embedded web server and yet can sync to a database server and offers conflict resolution and all the stuff you need to make this work. So if you need to create a resilient application that works even if your internet connection's dead but does sync and work together once it comes back up, then we've got some stuff for you. Whether you're in the cloud or in a set of data centers, Couchbase supports high availability through replication and disaster recovery through cross data center replication. This lets you support multiple data centers or multiple geographic zones for the case of the cloud. This is highly configurable but now since you can read and write locally and have the right data go to other geographies. Most applications that go no SQL are greenfield but we've seen more migrations recently and there are a lot of reasons for this. The number one reason is that there's an application that while it works, now has the scale. Now there are new demands whether it's because a cell provider wants to give users more visibility into their data usage unless make the external service remote, remotely available or a grocer that suddenly has a lot of online orders or a top financial company that has ever increasing volume and is pursuing more service orientating to solidate architecture. Each kind of follows this general pattern. Lots of change, more rapid change, more scale but they need it to be more reliable. When we strategize, we need to think about some things. What kind of risk can we tolerate? What skills and expertise do we have? What is the cost of migration? What are our performance and scalability requirements? There are a lot of different options we have when pursuing this. Do we want to rewrite the whole thing? That's a lot of effort, a lot of risk. It does give us an opportunity to achieve the most optimal performance and scale. Another option is to migrate the database and totally rewrite the data layer in the application. This is less effort, less risk but still quite a lot of effort and risk. Performance and scale is probably almost as good as rewriting but we've got to consider the risk and the effort. We can keep everything as is but refactor our data and logic and RDBMS schema to a best practices schema. We're keeping our business logic, most of our data logic but pursuing optimization upfront. Still a fair amount of risk, still a fair amount of effort, a lot of optimization, a lot of performance. We can also optimize layer, basically just migrate the table rows documents, make a few changes to our queries as possible, make a few changes to our queries as possible. Our initial performance and scale may not be great but it'll work and it's low risk. Finally, we could just not bother optimizing it and host it. So really we're balancing performance and scale against our effort and risk. Generally, I see organizations doing more of a two or three than a zero or one. Some maybe do four for applications that can be moved over just for consolidation reasons that the performance or scale requirements aren't very high. So we're gonna focus sort of on that option number three, optimize later. So how do we migrate without denormalizing the data into a big document? First, we need a no SQL database that supports SQL, asset transactions and joins. We need to understand how the tables and rows relate to documents. There will be SQL dialect transitions similar to when you go between two RDBMSs even if those two databases support the ANSI standard. Anybody that's done this knows that they've got to make some changes. Once we get everything running, we'll experience lower performance on more servers. We need to expect that upfront. So if we just do this transition, we don't do any optimizations. We'll probably have lower performance using more servers. So let's set our expectations up front so people aren't like, wow, that no SQL database wasn't very good. Moreover, when we moved to distributed architecture, there's a different sweet spot. So for cache base, a key value lookup might be faster because we're gonna do it out of memory. An index lookup on five rows, not in the cache is probably slower than on a single server database. However, a query that hits lots of rows might be faster because we can pipeline it for multiple servers at once. I'm gonna say a lot of might and maybe because it depends on your topology, your data and your application and how it uses the data. But we shouldn't expect the performance to be one for one in all cases. Let's look at how things relate between your RDBMS and couch base. A set of typed like fields are analogous to a table. So what I've done here is I've got my relational table on the left. I've got a document on the right and you notice the document has a type and that that type is also included in the ID. I've got the same sort of ID as on the left and on the right. So I've got a user ID that also includes the type. So this is basically, we've got a bucket. It contains multiple different documents but this is analogous to a table. So a table is a document where type equals user that's analogous to the user table in our RDBMS. A document is analogous to a row. Light name fields in a document are analogous to a column. A conventional relational model tries to have minimally redundant data. This minimizes storage, enforces a schema, does joins in memory on a single server. It also requires transactions to put Humpty back together again. So where in my document, I've got everything potentially in one document, I don't need a separate transaction just to put all of these different pieces of the entity together. I do have to do that on an RDBMS. The document's fairly denormalized. It generally aligns with how your application users data. Normal single document reads and writes don't require transactions. This means fewer joins and fewer transactions. This ensures scales better horizontally. For couch base, we query on a bucket. So when you see the from there, that's on the bucket. Remember, it's more like a database than a table or a database instance than a table. What makes this a table is that we specify the type. These two queries do the same thing. One on an RDBMS, one on NoSQL. We do support, so keep in mind the differences. The table equals bucket plus type. You can have many different document types in a single bucket. The ANSI, there are ANSI joins and we do support other SQL conventions. But there are some, are no SQL, or are SQL dialects called in one QL or nickel. There are other sort of JSONisms basically like unnest and nest when dealing with embedded documents. Indexes are more important on couch base. There are other details that we're not gonna go into great amount of detail today, but there are other things to consider. But you can kind of get a taste for what this might work on. When you're creating an index meta, this meta keyword allows you to refer to the field names. When you look at the word GSI that stands for Global Secondary Index, couch base has other types of indexes. Again, gonna skip over some of those details today. A few more notes here. So changes within a document are automatically atomic. So what's that mean? We don't need a transaction if we're just doing a bunch of changes on a single document. This is why when we say that you don't really need transactions as often in a no SQL database, it's because you don't have to put together all the different tables together. Now, if we're just hosting our SQL database one for one, we are gonna have to put tables back together. We will need transactions. And if you look on the right, this is sort of standard Java code for doing transactions in an application. Changes to multiple documents without a transaction are not atomic. So if we are doing a query across several documents and then we're making changes across several documents, this is all not transactional unless we actually code in a transaction. Couch Base 65, the most recent release includes a transaction API allowing multi-document transactions. And we support both synchronous and asynchronous. So if you're a developer and you've started doing more event-based reactive sort of coding style, I put the synchronous code sample here in the slide because I think everyone can look at this and kind of understand it without understanding monads and all of that kind of stuff. But we do support the asynchronous version as well. So let's talk about, okay, we've hosted our, we understand the difference between a table and a bucket plus a type document. So we understand that that's basically the bucket slash type document is analogous to a table. So we understand that, but we've got our one for one hosted relational schema on our NoSQL database. Well, let's talk about what we do now to optimize things. So we did that performance, and maybe we wanna make some changes. We haven't met our performance requirements yet. What do we do? So first thing to consider is that joining and transactions joins and transactions are costly and that doesn't scale as well horizontally. Remember our relational databases designed to scale up on a single node really well, doesn't scale as well horizontally. NoSQL databases are designed to let you just add more nodes as you need more scale and in many cases more performance. Your well-designed application code is a guide. So I said well-designed, because if your application's designed poorly, well, it won't be a good guide for anything. But if person contains addresses, but looks up orders, well, that's a good hint that person contains addresses should address, should just be contained in the person document, but that you might look up orders as a second entity. So we might have an orders type and a person type. We can look at our application code and kind of realize this. One of the things when we're optimizing, we should think about is when we go to RDBMS, we do a lot of sort of transition. We flatten things out, we create more pieces out of it. And that sort of gives us an idea of how we've sort of de-optimized to meet the semantics of a relational database that are different from our application. When we look at our application and we look at a NoSQL database because it supports a put-together type, we don't have to do some of that work. So if we do less work, we've essentially optimized things if that makes any sense. So think of in terms of entities. In the scope of your application, does this entity have a lifecycle outside the thing that always references it? If you've come from a Java background and use Hibernate or another object relational mapping tool, you get the same sort of advice from your object relational mapping tool. And so that's a good sort of skill that sort of transitions from a developer perspective. Can you reduce the number of explicit transactions required? So when we're trying to optimize this thing, can we, should we put something together just because it reduces the number of joins and transactions? Sometimes the answer is, hey, we're gonna put this together into one document because it'll reduce the number of joins and transactions. And have you met your performance and scale requirements? So it may be fun to think, okay, I'm gonna make this perfect NoSQL schema kind of setup, but if you've finally met your performance and scale requirement, well, you can stop. I guess that's generally the best advice for any sort of optimization scale effort is to have a performance and scale requirement in mind. I need to meet this many transactions per second. I need to make these things this fast. Once you meet that, you can stop because you can always find more optimizations and how do you need to stop it? So have a metric in mind. So when we wanna reduce joins and transactions, if we look at our setup, on one hand, I've got, on the left, I've got sort of this relational setup here. So I'm doing a transaction. I'm updating the savings table. I'm setting some stuff. I'm updating the checking table. I'm setting some stuff. I've got two different tables here. On the right-hand side, on the NoSQL side, I put these things together into one document. This is not a very realistic example, but it gives you sort of an idea. I put these into one sub document, balance and savings, checking, and so on. So I'm able to do one update and I don't need to have a transaction because I just do two updates on the same document. This reduces the number of transactions I need. This is when you're optimizing, you need to think, okay, well, could I just combine these things so that I don't need a transaction? I don't need a join. If you're a DBA, come from a DBA background, one of the first things you look at when developers send you a query is, is it complex? Can I simplify this query? Can I reduce the number of joins? Can I make that a less complicated setup? And generally that's one of your first sort of operating optimization plans. That's the same sort of idea here. We're just looking at the object model. So you can look at your logical model and if you guys are like saying, okay, logical model, physical model, blah, blah, blah, and you think, wow, I like doing this in Irwin, well, I've got good news for you. Couchbase is a partner with Irwin and Irwin supports Couchbase. So if you are taking a relational model and you're trying to host it on a NoSQL database, Irwin's actually a pretty good place to start. So you might consider using Irwin to sort of reverse engineer your relational model if you don't already have it in Irwin, into a logical model and then use Irwin to manage your physical model on Couchbase. So something to consider when you do this. So look at your logical model, look at what is your object in this? So one option we have is to embed days. So if we look at our overall setup, we've got an order, an order has things in it. It has quantities of those things. We can put those together into a document. So for us, we took order, we embedded pay type which embeds product. We can also do embedding and referencing because, hey, our products sort of have their own life cycle that's independent of the order. So we may embed the ID of the product but store the quantity as part of the order. So we've got order, it has items, it references product just like you would reference in a relational database but we've got the quantity embedded in here that might be in a relational database. We'd have a join table in the middle that would map order, we'd have order, order items and that would reference our product type. In this case, we can embed basically that order items table if you will. So in a NoSQL database, you can have both embedded objects but you can also have arrays. On the left hand side, I've got phones and I've got home. On the right hand side, I've got phones but it's an array of objects. And each one has a number of types and what have you. I could have an additional, I'd have a comma after the right-handed bird bracket if you will and I'd have a comma there and then another open and close for the next phone. That wouldn't fit on one slide now, would it? All right, so what should we conclude? Well, migrate first, optimize later, reduces risk while increases performance and scale over just hosting it. Joins, multi-document transactions are more costly and distributed architecture. So expect a one-to-one migration if we just host and just change our SQL queries as little as possible, change our object models as little as possible. We could expect it to be slower on more hardware. Embed documents as an optimization. The queries can be converted noting couch space and JSON differences. So you're still gonna use your SQL skills but you'll have to make some changes for the dialect and because JSON is different than a flat row. Asset transactions are available but they're not as needed as often when we optimize our schema because we don't have to, when we have orders and order items and product, we've got three tables basically. We've got to have a transaction just to map between orders and order items. If the order items are basically embedded in the order then we don't have to have a transaction just to update it. Finally, have some performance and scale goals in mind. This is the part people skip. They're like, well, we never measured it. We'll measure it, figure out what you need. Come up with a goal, even if it's a straw man goal at first and once you meet that stop, if that works good enough for your customers and what have you, then you're done, stick with it. So that's what I have. Thank you guys. Any questions? Andrew, thank you so much for this great presentation just to answer the most commonly asked questions or if you have questions for Andrew, please feel free to submit them in the bottom right hand corner of your screen and to answer the most commonly asked questions. Just a reminder, I will send a follow-up email by end of date Thursday with links to the slides and links to the recording of the session to all registrants. So diving in here, Andrew, are you indicating that we can use something like CouchBase to replace the SQL database for highly transactional things like banking? I thought you need ACID in such a situation. Yes, and CouchBase supports ACID. So because CouchBase supports ACID, CouchBase supports SQL, you can use CouchBase as a source of truth and in a highly transactional application. Would you make your ProcessingFasterRDB queries store code and optimization? How do you really compare and do you have benchmarks? We do actually have some benchmarks on our website. So if you go to our website or search for Alterose CouchBase, we have benchmarks against, I believe it is MongoDB, which is another NoSQL database. DataStacks Cassandra, which is another type of NoSQL database as a column family. And I think MySQL, just so that you can get a taste. Obviously, the license for the two most popular enterprise NoSQL databases prohibit you from releasing public benchmarks, I believe. So you can find those to kind of get an idea. But again, this is like, if I'm doing a single join with a short number of rows and what have you, and I don't have a lot of scale and I don't have a lot of data, well, that probably will perform better on a single server, on a single computer, on a single CPU, on a single disk. Once I have scale and performance requirements, then that won't perform as well on a single server, on a single CPU, on a single disk. So they're gonna be like, okay, well, I just did this simple query. Well, yeah, that's gonna perform better on a flat file with grep, honestly. But when you get a more complex, when you get a query that's going across lots more data, or you've got a query that's, or you've got a lot of queries, and you require more scale and what have you, then our requirements are different. So in short, it'll perform better at scale on a NoSQL database. It'll perform worse at low-end kind of scale, with the exception of E-value lookups are usually in memory on Couchbase. And do you recommend migration to NoSQL for all types of business needs based on your use cases? So there's a lot of different reasons people are migrating to NoSQL databases that go beyond the traditional. So I'm gonna make a qualified yes, meaning, okay, do you need to migrate your Microsoft Access database that has 10 rows in it and you're the only user? Well, probably not. But if you're looking at your license fees going out, going crazy, you're looking at putting out more and more changes to your applications, you're looking for higher reliability. These might be reasons, the size just performance and scale that you might consider migrating to a NoSQL database because you can have the same sort, you can have, you don't need Golden Gate and Data Guard and all of these sort of complex solutions that add on and add on the license fee as a multiplier. You can have that architecturally out of the box. Moreover, if you're doing mobile applications and you need resilience, sometimes that's because you've got lots of different locations and they need to be able to sync up to something or you may have lots of users with mobile phones and they need to be able to work and collaborate on something and then sync up. You need a platform that supports that. So I'm gonna make a qualified yes. There's always a, gee, if you're doing grandma there's a dress book and there's one, two, three users to it and performance doesn't matter, reliability doesn't matter, scale doesn't matter and it's never changing and you've got money to spend on Oracle or whatever then leave it in place. Once some of those things aren't true then it's probably time to consider a NoSQL database. And we're getting a lot of specific questions on install requirements of scale limits. I assume you have links to that that we can include in the follow-up email and make sure how... Yeah, absolutely. So I think the biggest sort of install requirement that I do wanna cover is generally speaking for something that's not just developer on your laptop, you're gonna want three nodes minimum and there's various reasons for that from a clustering and reliability standpoint but that would be sort of your minimum installed with the three nodes. You can obviously just install it on your laptop right now if you go to couchbase.com and download it. But really that's sort of the minimum, very minimum setup. But yeah, I'll send you guys links and other resources in the follow-up. I love it. Yeah, suit those my way and I'll make sure I get that out and to that everybody. And because one has to specify a bucket as well as a type in order to select from a quote unquote table does that mean that different buckets could host different data and that one can miss data if one selects the wrong bucket? So that's probably not a super common problem. The real setup here for the bucket you should think of as basically a database instance. So could you miss a table if you selected the wrong database instance? So if you did select from orders with the app sign on the old Oracle sort of notation from orders at some database instance and it was the wrong database instance. Yes, you could miss that too. So it's the same sort of problem. So yes, but that's probably not a problem that most people have. And you mentioned Irwin is a modeling tool that integrates with Cachebase. Are there any other tools as well? Yeah, we have other things that you can use and I'll send that in the follow-up. Irwin is sort of the one I've used since gosh since going, oh wow, I'm feeling old over 20 years and it's probably the most common but I can send you guys some follow-up but Irwin is sort of the most sort of famous modeling tool so it came to mind. And can we get a NoSQL catalog into a metadata management tool and then could we draw a lineage tree? I will have to ask someone else that. I'm afraid that that doesn't map to my knowledge. No worries, what's the largest database that Cachebase can support? So we have, I can't go into super customer specifics but we have customers that have in the thousands of nodes and what have you. If you look on our website, you'll find some use cases from major airlines to companies like AmEx and what have you but there's not a theoretical limit that you're likely to hit in that some of the largest companies in the world with some of the largest data volumes in the world are using Cachebase. In fact, whether you know it or not, you're already a Cachebase customer because it's virtually impossible that you wouldn't be using Cachebase and some of the applications and companies that you do business with today. I love it. And can you speak a little more about how Cachebase enables shared nothing architecture? Sure. So Cachebase, each node, well, first off, it's the clients get an updated map whenever they communicate with Cachebase. So every time they make a call, okay, the first call fails because that node went down it fails over the next node. That node then gives us an updated map of who it can talk to, so smart clients. You can also do this with a load balancer and hit the restful services if you need to. So first off, the smart clients basically keep the initial topology map or get an updated initial topology map in order to hit an active node. When a node goes down, then Cachebase automatically rebalances the sharding basically. So when Cachebase supports auto sharding, so whenever you add data, it automatically assigns it to at least two nodes. This is all configurable, of course, but at least two nodes. So there's at least two copies of the data at all time. If a node goes down, then that gets rebalanced. When the client talks to a node, that node automatically knows where to communicate in order to get the client the data that it needs if it talks to the wrong, quote unquote, node. There is no basically master election as there is with other databases. At all times, you have this sort of updated map. It hits memory, so it's a memory-first architecture. So things are written to disk as sort of a right behind Cache. And that's basically the crux of how it works. There's a lot more sort of innate detail in the devils and the details and what add you. Oh, it's also basically asynchronous by default. I love it. There's so many great questions going on here. And if you have a question for Andrew, please feel free to submit it in the bottom right-hand corner of your screen in the Q&A section. And do all major cloud platforms support CouchBase? Yeah, so you can deploy CouchBase on any of the major cloud platforms and people have and are using CouchBase today on all the major cloud platforms. A lot of companies choose CouchBase for their multi-cloud architecture because a lot of companies want to avoid having a single cloud provider or they have reliability, data sovereignty and global requirements that are not met by a single provider. So absolutely. Additionally, if you want, you can use, you can, although it just was announced and released in beta and the general availability will be later in the year, you can sign up for the beta for CouchBase cloud and that'll let you have a fully managed cloud-based NoSQL database. One of the things that's sort of interesting about CouchBase cloud is if you use a different cloud or as a service database, they upcharge you for your underlying cloud provider. So you're buying a bunch of Amazon, you're buying a bunch of Azure or whatever. So they upcharge you for Amazon. So you, they buy Amazon and resell it to you at an upcharge. For CouchBase, it's bring your own cloud. Sort of like bring your own deer, right? But bring your own cloud. So you can provide your own cloud infrastructure, negotiate your own deal with Amazon. CouchBase just charges you for the use of the database rather than upcharging for that. And that's big if you're working for a big company because they generally have a cost center a lot of our clients are significantly bigger than all of the NoSQL vendors combined, right? So if your market cap or sort of your IT spend is bigger than even a public NoSQL vendors market cap then you can guess that you're getting a better deal from Amazon on your underlying infrastructure as a service charge. So you wanna negotiate your own deal with Amazon for the IaaS and then you want to just pay for the NoSQL database. And that's what CouchBase Cloud offers you. And there's a lot of different variations of this question, Andrew. With your customers, are you seeing a blended model with relational and NoSQL or are your customers majority of your customers moving exclusively to NoSQL? It's a mix of both. I wouldn't say that most companies are like, okay, I'm gonna rip out my relational database and immediately move it all to NoSQL. There are customers that are doing that. They generally do it piecemeal. They do it as the applications being updated as opposed to an application that's just sitting there with no new users and not a significant uptake in users or requirements or what have you. But there are companies that as a strategy including a large financial company are consolidating on CouchBase. I would say the vast majority have both and probably the vast majority have of large, since our customers tend to be larger vendors or larger companies tend to have everything. But they're running their mission critical sort of applications on CouchBase and yes, they also have relational databases. So combination of blended, some are actually migrating to CouchBase as a strategic sort of initiative. And what do you do for end user reporting? Is there an ETL tool or is there a replicator for transaction by transaction roll off? So there are a lot of ETL tools that will work with CouchBase and there's a large ecosystem that'll work with CouchBase. For that, I'm gonna kind of roll you to our website on the list of partners and what have you and you can look up through a pretty large set of partners and tools and whatever that work with CouchBase. Because we support SQL, I mean, you can use Tableau if you want to, you can use Excel if you want to as far as querying and doing reports and analysis and that sort of thing. So you've got quite a bit of that or just sort of monitoring and what have you. CouchBase has a pretty nice built-in administration module that you can look at the pretty screens and ops monitoring whatever on our web tool. And Andrew, what's the number one reason you find customers moving from relational to non-relational? So number one reason is that they need a performance, they've got a performance and scale requirement that they're not meeting. I would say the number two reason is cost. I'd say probably tied for number two or possibly rising to number two is reliability and the rate of change. It's easier to ring to change a schema, to move a new version of application on CouchBase than it is to relational database without having to restart things without having to rebuild a schema or rebuild various things that require you to take down the cluster. So we're seeing sort of the one, two, three would be, hey, I can't mean my performance and scale requirements, two, I don't want to pay this kind of licensing fees when you start having lots of nodes and needing reliability, what have you. And then sort of the third is that I can't meet my application change requirements and meet my reliability requirements with my existing database technology. And are there any scenarios, Andrew, where CouchBase is not recommended? Oh yeah, there's plenty. While CouchBase does, the first that comes to mind is, while CouchBase does have an embedded NPP, this is for like real-time analytics. It's not to go source against petabytes of data or do something where you'd need a materialized indimensional cube, right? So this is, there are fewer scenarios where people are doing that. Sometimes they're doing less good analytics that are faster, and that's where CouchBase may be appropriate where it might not have been in the past, but any place where you've got to do this indimensional cube and do this large projection and what have you will by means, Teradata and Ateza, whatever, those are your friends, but maybe they're not your friends, but they're the devil you need, right? But in the case of, but there are a lot more scenarios where CouchBase is appropriate, particularly in the operational space. I'd say if you've got, again, a small, not changing that often application with a small number of users and it works and you don't need high reliability, high scale, high performance or whatever, then why would you migrate that to anything, right? Leave it on MySQL or on Microsoft Access or what have you, but it's really when you start having more requirements and more reliability, more performance, all that kind of stuff that you're really going to start looking at making a change. It's a clarification from earlier. A benefit of normalization is reduced space usage and space usage is not an issue in NoSQL because of NoSQL's architecture. I'd say it's not an issue because disk got cheap. So yeah, we're gonna waste way more space. If what you're trying to do is store your database and as few megabytes as possible, then the NoSQL architecture is not going to be as efficient for that. I just say that's not a goal the way it once was. So you're trading something off, right? You could have your database in a tiny amount of space. Instead, you've decided that you want your database to perform and scale to a larger number of servers and be more reliable. So yeah, we're gonna waste a little more space there. There are updates coming in our future roadmap that may reduce that a little bit, but that can't be your top goal. If that's your top goal, that this may not be the technology for you. However, you might look at CouchBase Lite, which is a mobile embedded database that still gives you sort of this style architecture or sorry, it gives you documents and what have you. But yeah, I would say that if saving space is your most important goal, this probably won't be your favorite architecture. And is a denormalized database more difficult to enhance with new entities and attributes? No, quite the opposite, because you can just add a new document immediately, you don't have to do a create table statements and any of that kind of stuff. You can add a new field, you can add a new embedded document, an array, whatever to your document without doing any kind of schema updates, whatever you just go. So I would say exactly the opposite, that's part of why people have been choosing these sorts of databases. Andrew, I love it. And there's a lot of great questions here. A lot of these questions, I'll get links for, there's some really super, again on the size and the install and we'll get those links out to everybody. Andrew, thank you. Yeah, I'm sorry, I actually can't see the questions. The console crashed my console with the questions and it crashed shortly after the presentation began. Oh gosh, no worries, no worries at all. I will get you the additional questions that and to you and the team, I really just, the remaining questions require links and information that you guys have available on your website and the technical details for the installs and such and such. But Andrew, thank you so much for this fantastic presentation and thanks to our attendees for being so engaged in everything we do and all the great questions, we really appreciate it. Again, just a reminder, I will send a follow-up email by end of day Thursday with links to the slides and the recording along with the additional information that you all are asking for and we'll get that out to you. And I hope everybody has a great day and stay safe out there. Andrew, thank you so much. Yeah. Thank you.