PurePerformance - OpenTelemetry for Databases: Empowering DevOps through sqlcommenter with Nimesh Bhagat

Episode Date: October 11, 2021

Optimizing or debugging database calls has to become as easy as optimizing your application code based on logs, metrics or traces your observability platform provides to developers. It has to be doable by the development and DevOps teams who are becoming more end-2-end responsible which includes new database services that are running in some managed cloud service.In this episode we hear from Nimesh Bhagat, Product Manager at Google, how modern database observability supports development and DevOps teams to better understand, optimize and operate their end-2-end service flow. A great project Nimesh has been working on is sqlcommenter which uses OpenTelemetry to continue distributed traces started in the application into the internals of the database engine.If you want to learn more check out the sqlcommenter documentation or the Google Podcast on Cloud SQL Insights.Show LinksNimesh on Linkedinhttps://www.linkedin.com/in/nimesh-bhagat-b062354/SQLCommenterhttps://cloud.google.com/blog/products/databases/sqlcommenter-merges-with-opentelemetrySQLCommenter Documentationhttps://google.github.io/sqlcommenter/Google Podcast on Cloud SQL Insightshttps://www.gcppodcast.com/post/episode-247-cloud-sql-insights-with-nimesh-bhagat/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and center picture of Zoom as I'm looking at it right now is Andy Grabner, who is always here with me for some reason. Hi Andy. How is this possible? I'm a center picture and we're three people on the call. Yeah. For me it doesn't make sense okay well i have on the top i have it's a horizontal row with three and three is an odd number so there is a center to three so it's like center

on the bottom row but not on okay not center top row no the top row okay for me top row has like the low yeah yeah anyway you could do gallery view you could do side by side or you know it's it's you are the center picture of the three guests that i can see now if i hide my camera you'll be the left okay if i do you think our listeners want to listen to our i think this is their favorite part of the show i think finding out the stupid things we're going to say in the very beginning and waste their time before we get into the really important stuff is probably the the most entertaining part because this is about the only time that i talk yeah i give you i give you room for talking but i think that it's more important that uh that first of all it's people don't see it but we get we got our guest at least

to smile so we know that we are even though we are bsing around here it seems that at least we make one one person happy um and i think that's a perfect segue because we always perfect always always perfect yeah we wanna and i was actually interesting i have one more thing segue was my first company in the performance business segue software i thought we did performance testing no no no segway software performance testing and before they went into hdb based testing they started actually with database performance testing which is an interesting segway segway because nimesh our guest today will tell us a lot about performance on databases on how i guess developers can use the stuff that nimesh has been building and promoting with SQL Commenter and kind of merging it

with OpenTelemetry, that's what I hear. We'll hear about this. So Nimesh, without further ado, welcome to the show. Thanks for having me on the show. Sorry that you have to wait for so long to hear our forced, I don't know yeah yeah something like that anyway can you for the audience that that have never you know they haven't heard about you yet can you introduce yourself who are you what you do what's your background my name is

Nimesh Bhagat I'm one of the product managers on Google Cloud. I work on the Managed Databases group. I'm responsible for observability. One of my deep passions is to make technology accessible to every developer and every enterprise in the world, which means building robust but at the same time simple infrastructure. And observability is a tool to make that a reality so that's my passion and that's what i'm working on uh for the last couple of years very cool so it's interesting you said

observability is a tool um of course it's a tool that gives insights right to everyone to make sure that they understand what's happening now we we've been in observability before it was called observability i think that observability is the hot new trendy word and and it's very interesting because our uh let's say audience and the people that we work with on a day-to-day basis are responsible typically for large-scale enterprise applications where they deal about performance and we often focus on the application part, like the codes, the stuff that you can kind of impact as a developer, as an architect. And then very often, people just start then complaining

about the slow database if things don't go as expected. And I want to hear from you. What do you do? What have you done? And what are you going to do in the future to make sure that people are stop complaining the database? I want to hear from you. What do you do? What have you done? And what are you going to do in the future to make sure that people stop complaining the database?

Because we give them with observability the right insight so that they can make things, optimize them on their own, and not just complaining the database. You're so right. Observability is becoming the new word. But folks like you have been working on this for years. When we looked at this overall landscape, we saw three things which is making it even more important.

One is changing platform. Second is changing application patterns. And the third one is changing persona. Platform is customers are moving from self-managed to fully managed on cloud. The operation goes away. Along with it, the many who are moving from proprietary software to open source software on cloud as well.

That's from a platform point of view. Second is application patterns. Initially, you would have a single application instance talking to a database, this is 10 years back, but now you have this set of microservices talking to each other and talking to a number of database engines. And that makes world further more complex.

The third one is changing persona. Keep hearing DevOps, rise of DevOps. What does that develop means for databases we did a user research and we found more and more increasingly when at 2 a.m the pager goes off it is the developer who's picking the column on the dba and which means that all the three changes the solution to the problem the problems are changing but the solution to the problem. The problems are changing, but the solution to the problem needs to be different.

And that's where what we took a step back and we thought the modern database observability needs to be application centric, which means you do not see database in isolation, but you see databases in view of, from a point of view of your application, because the developer cares about the whole stack, not just the database.

And this is what we've been working on at Google. And so I took some notes here. That's my, I know the people that listen to this can't see it, but I always like my eyes wander off to my little notepad here um and i think this is fascinating and i want to add to this because you said modern database observability needs to be app centric because it's the developer in the end that picks up the hopefully not the pager but maybe it gets woken up by the slack message or something like that but uh the well the other thing uh i guess developers probably have a different perception

or a different requirement on the data they're expecting for troubleshooting, right? Because I assume as a developer, I put in either my logs that I can then look at or I'm using OpenTelemetry to instrument my code to get my traces. And if I'm now also responsible end-to-end for all my microservices, including the databases, I also want to see this data in context. Is this right? Yes. And I'll again say the three things which you saw, how developers could be different

than DBAs. One, as you said, they start their journey not inside database. They started in their preferable application performance monitoring tool. Many of our customers use Dynatrace. They've said as GCP customers give all of this information in Dynatrace. That's where we start our journey. That's one. The second one, as I already said,

is they look through an application lens, not just database. The third one which we have seen is the developers, the time and expertise they have to solve the database or resolve database issues is very different than that of a DBA. So you need to make it simpler, right? That's how we see that the world is different for developers than a DBA. Sorry, Brian. Yeah, I was, you know, I've been always thinking about the DBA or the database analysis part, right? And we've been seeing, I've been seeing this for years. I'm sure you have, Andy, too, where we always get asked, well, what can we do on the database there?

How do we see things? And there's a lot of ways that we point to this but quite often it falls back to all right get as close to the problem as you can and then go turn to the dba right because the dba has these magical tools and the one thing i remember so i used to work way back at you know webmd and mtv and a bunch of these other places doing performance and every time i'm talking with a customer i usually make this joke and everyone laughs because everybody seems to have this universal experience with DBAs, is if you go to a DBA and say, there's something wrong with the database, they give you the worst look in the world, right? Because, you know, it's really tough. And I'm not making fun of DBAs. They have a really

tough job and it's a really hard thing to deal with. But it's always been that you can't just go to them with something's not working or it's slow. So I've always felt there's been this sort of gap with what the developer can go to with a DBA with. And it seems to be a little bit overlooked for too long, I believe. There's definitely a lot like tools like ours can do to narrow things down, but you know, and maybe I'm jumping ahead here, but it sounded like we were going there curious about how, what you're doing to solve all that. But I think I might've jumped ahead there a little bit. So apologize if I did, but that to me is like the magic, the piece that's been the Holy grail to me is how does a developer really solve the problem on their own with a ton more data than they already can get?

If I may add something, a data point, what we keep seeing in the field is as customers move to cloud and manage databases, they start doing more. So the instances per DBA just explodes many times. And there is now this push and hunger from many of these DBAs who really want to focus on strategy tasks to make database troubleshooting self-service for developers. And we've seen many companies trying to stick

their own tools to make this possible because there is no good tool according according to them, available in the market. So plus one, I think this problem is becoming more and more acute as we look at the scale of cloud. Well, yeah, especially because a lot of these databases in the cloud are the on-demand ones. So in theory, a developer can spin up some database instance and start using it. You might not even have a DBA involved. And then what? Yeah.

What do you do then? Like a developer is not going to be a database expert. And a lot of these newer cloud-based databases run differently than they have in the past. So what do they have to do? Dive in and read all the documentation and try to figure all these things out. It definitely is opening a new world of performance analysis for that database use case. So, Nimesh, from this interesting point,

so basically the role of DBA is obviously changing, has changed over the years, but especially when moving to fully managed services, as Brian has just said, right, there's no DBA anymore. I mean, there are DBAs, I guess, at Google and the others that are providing these services. But from a consumer perspective, as a developer, I don't go to a DBA anymore because I'm just consuming a service. My question is, and kind of to add to what Brian said, does this mean that the developers now need to understand the internals also of that service that they consume so that

they can then optimize it? Or do you provide services or do you have a lot of smartness built into your database engines or storage engines or whatever your service is? They will then automatically optimize themselves because who do i go to what if i if i feel something is too slow and i don't know how to optimize my queries anymore what's my next chance so i want to start with the premise right that dbas are critical because databases are hard. Anyone has worked on database, especially the databases which have been built

20, 30 years back. Cloud SQL is very different than Spanner, which we have in our portfolio, for example, right? Spanner handles a lot of scale for you, for example, transparently, right? It handles regional failovers easily. But there are these thousands of databases out there which are present on cloud, and those are not easy.

How I see this is an 80-20 rule. You want to make sure your 20% problems, which are with 80% frequency, are handled by developers. And database experts, the DBA is focused on the hard problems. That's how I see this. That's the reality, right? Hopefully someday, you know, the autonomous databases become a reality and talking to someone, which one will come first, autonomous cars or autonomous databases right this promise is already always there and there are elements there's a lot of innovation happening in the industry but they're

not truly autonomous today that's according to me so now going back to your original question is there being things built in order to take this toilet away i think this is a three-step journey right first you get the information then you make it easily consumable, then you give insights, then you give recommendations, and then there is automation, right? And there are many areas where there is automation. For example, scaling made easy, you don't have to add storage, the storage keeps growing.

Or, you know, memory management has become easier on many of the systems. It's not one polygraph. It's dead by a thousand cuts in some ways that you keep chipping away small, small things. But then there are still a long deal of things which can happen. So in this journey, taking a step back, in this journey, the key question over here is,

if you're a developer, how do i make this information easily accessible and tied together between applications and databases right this is something which we have done with sql command that we sent you so yeah i don't i don't think there is a holy grail answer over here it is a journey no that's perfect but i was was just curious, right? So basically, if I hear this correctly, because I kind of thought in the future there might not be DBAs anymore, maybe in a very distant future. It's not that they're not there anymore,

but their role is changing. I think it is already changing, right? Whether they are providing their own troubleshooting as a self-service, as you said, by building their own tools or providing mentorship or, I don't know, review sessions with the developers to make sure that they are writing better code against the database to make everything more performant and maybe that changes even in the future but now coming thanks for the segue again another segue

to sql commenter so the as far as i understand um we from let's say more from the application monitoring side we've been talking about distributed tracing for many, many years. Brian and I are working for Dynatrace. We've been doing distributed tracing since the inception of our company 15 years, 16 years ago. Thanks now to OpenTelemetry and other initiatives, we see broader adoption, especially standards around it, which makes it possible for vendors of let's say frameworks to auto instrument their code and now the sql comment as far as i understand you're basically taking open telemetry from the app through the database database client library

into the database and can you just help us understand what really happens technically and also kind of like you know where does the data end up or like what additional data do you enrich from the database side to the trace and and what would i get as a developer when i use sql commenter yeah let's get into the how part over here right The problem which we are trying to solve over here is, if your application called a database, you would not. Number 1, what is the latency inside the database? Number 2, what is happening which is causing that latency? That's the top down and then there's a bottom up view.

You see a busy database, and you have this tens of microservices. You don't know which one it is. You want to get a forestry, not a query. You could have thousands of queries, and then tied back. You saw a noisy neighbor, tied back with part of the application code is causing this.

Now, how do you do this? You need the application telemetry tied with database telemetry. And what we did is we introduced back in January when we launched Cloud SQL Insights, an open source library called SQL Commenter. There are two parts to SQL Commenter. There's one that's standard. The second one is the library itself,

which auto-instruments the comments. So let's talk about the first one, format, right? When any SQL code you write, you can write a comment next to it and you can add tags, model, view, controller. Those are tags. That's how you can tag a query. And then we pass the open telemetry

context. So the span gets pushed to database in comments. The database engine picks that up and now you can imagine you can aggregate all your telemetry, for example, the spam gets pushed to data visit comments. The database engine picks that up, and now you can imagine you can aggregate all your telemetry for example with tags. Then you can say, the payment services started spiking up at 12 in versus this random SQL comment,

which is 10 lines for you to even understand what is happening. In terms of tracing, database, as you know, has rich database query plans. What inside Cloud SQL we do is we sample, we take executed query plans for the top queries, biasing to a stock query. We create this executed query plan, we tie it with an open telemetry span

and then we write it to our cloud monitoring product cloud press so that customers can take a look top down the entire trace of the stack and this can be exported into their favorite apm tool as well so that means again if i because i looked at some of the of the blocks that you wrote and we will definitely link to them as well you are instrumenting the that client library that means when you see a call from the application to the database client library being done you're adding an additional piece of metadata to the sequel in a comment field like the trace ID and then this gets passed over to the database side and then on the database you're starting another span you basically

you know say hey this is my part of the trace and I know I'm connected to the trace from the application side and then you're filling it up with some sample data that's great now and i like the the two use cases that you mentioned right because on the one side this is also what we see in the years we've worked with customers there's one use case where you want to say why is this particular transaction that's slow right so you look at a trace we call it a pure path and say hey this database query took 50 seconds and then you want to go in and want to understand the execution plan and what happened. You also, and I think this is also nice now with distributed tracing, that you can see the time,

the latency between the time the request exited the client code until it reached the database. And I think that's also very important. So you can see if there are any latency issues. Maybe you are connecting to a database in the wrong region or just whatever else happens. But this allows you to say, why is a particular statement slow? But if you reverse it, and Brian, this is what we call

doing backtrace analysis. So I'm looking at my database. I have a spike of a million transactions more than normal within the last hour. Where do they come from? So that's pretty good. And do you see in your work, are these the most common scenarios

where people use SQL commenter now in open telemetry? Or what are the typical problem patterns people find? Do you have anything new for us? Yeah, so there is a dimension of SQL commenter which I did not talk about this. And this is what I was blanking on. The third thing which developers and DBAs are different is use of ORMs.

So what you see is more and more adoption of using ORMs so that developers would write database code in their favorite programming language, and they use ORM packages to do that. Now, if you have any time diagnosed in ORM, this is what one of the customers told me, ORMs are so easy to write and so much hard to debug. Everyone enjoys it until they stop not performing well.

The reason is ORMs create what i call this app database gap you write the application code and you might have three four five sql queries that created and you cannot tie them together and the second part of sql computer we understand that is that we have across with six or packages, if I remember correctly, where we auto-instrument the code, which means your application code, whatever SQL it creates, we auto-tag it. So now when you're looking at your database

and you see a SQL query, you can type back to each piece of code, which is the other big use case why customers do use SQL for mentor. So that's one. The second one is a more meta picture, right? So managed databases have made things harder for application performance monitoring tool in some ways

because a lot of times this connection between application and databases is done through some extensions or plugins right an apm tooling will drop in an extension or a plugin but because of the security posture most managed databases won't allow you to do that so the the other use case is it's a must-have that for anyone to look into a managed database, you need a way to tie these two together. So it's more become a necessity that the database should be doing this versus relying on the API to do it. So those are two things I wanted to highlight.

Yeah. So I mean, Rahim, when he talks about OERAM, the first thing that comes to mind is Hibernate. Do you remember? Yeah, so the, I mean, Brian, when he talks about ORM, the first thing that comes to mind is Hibernate. Do you remember? Yeah, yeah. But actually, before you talk about that, we're introducing ORM. And for anybody who's not familiar with ORM, you want to give a quick rundown of what... Do we have a jingle? It's an object-rel relational mapper right as an image explained as a developer you have let's say you model your data the data that you access in classes or in whatever construct your

development language provides and then a magic magic library that's called the or mapper is mapping these objects to the relational database, so the database behind the scenes. And in order to fetch the data and then convert it into objects in memory, database statements need to be generated. And they are sometimes good, but sometimes because these OR mappers are very generic, you often end up-

That's your Hibernate reference. That's your Hibernate. Hibernate is great, right? I mean, it's very flexible, but if you use it in a generic way, you also get generic SQL statements that are not optimized necessarily to a use case. And what we've seen, I think still,

some of the most popular blogs we wrote 10, 15 years ago now were optimizing Hibernate, the queries, the caching and all that stuff. So, Nimes's yeah it's interesting right because we've been talking and tracing we've been tracing this for the last 15 years and still it's a big challenge and it's great that you're also addressing this now with the work that you are doing and instrumenting it automatically also through open telemetry it is fascinating we maybe we need to you of brush up these old Hibernate blocks.

See if that's still valid. So you mentioned, help me understand, you are, if I'm a developer and I want to go with a managed database offering, how do I in the end really get to my data? Because I assume that you are running these databases, but because behind the scenes, there's some instance, I would assume multi-tenancy. So that means you have multiple small application teams, maybe sharing at least physically the same database service.

How do you then make sure that the data from me only gets to me and not to somebody else? How does this work? For sure, I understand this question. So what I'm saying is if I sign up for a cloud database instance and you sign up for a cloud database instance, then I assume that you're not just standing up two separate instances of that database, but probably your database is multi-tenant capable,

unless you really have really separated the instances of the database. Because what I want to make sure, if I call into the database, then I get my data, and you get your data. But there is no problem that a shared database is sending data that doesn't belong to me to me. Right. So I think the number of database types, I cannot generalize this, but

let's say Cloud SQL, for example, what we provide is manage MySQL and Postgres and SQL Server. And the access posture is no different than what you would do on train right when you request uh cloud sql for let's say postgresql we create an instance this is a vm the standard internet you don't get to see the vm it's a standard of vm with the database engine running in it and you would access it exactly the same way you would access it if you were managing your okay okay so i think that answers my question i had the wrong assumption so you really And you would access it exactly the same way you would access it if you were managing your own. Okay, so I think that answers my question. I had the wrong assumption. So you really, you have individual instances, so you manage individual instances per every

request. I thought maybe you are actually sharing some infrastructure. Multi-tenancy, yeah. Multi-tenancy of a database, right? So where you say, hey, we have 50 developers like Andy, and they're all just writing small blog applications, and we are just standing up one big MySQL cluster, and then we give Andy his little database, and Brian his little virtual database on it.

But it seems these are really truly managed services and dedicated services. I can't imagine what it would be like to work at a place where there were 50 developers like Andy. I think one is already enough. Looking at my code. You're right. Awesome.

No, it's okay. So you are enabling and just I think rephrasing again, we're seeing a shift in the way application ownership is managed, right? Because we're moving to a model where application teams or development teams are to provide a development-friendly, development-centric way to access any type of troubleshooting data, including traces.

And I think that's a very important message. And you are doing your part of the job to make sure that developers that use Cloud SQL, that they get these end-to-end traces. Yeah, that's the future. And one of the motivations for us to open source this and now merge it with OpenTelemetry is, we see, for example, we see a lot of download of SQL

coming to Godfrey is not even using Cloud SQL, which gave us a lot of confidence that this is a problem which is global in nature, right? It's not GCP-wide only. And what has been amazing is now as we are merging this with OpenTelemetry, we will want to extend this to more languages, more ORMs, for example. Have the ecosystem, as you saw in the blog post, Dynatrace and many other APM vendors, OpenTelemetry community is putting their weight behind this standard.

So what this is doing, if you see the world prior to this, the ecosystem, so the customer impact was every team has a favorite APM tool in many ways, right? Based on the sophistication. But if you went to your IT team or DBA single, I want my APM tool, they were limited to one or two. The reason was someone had to drop an extension inside the database, and that comes up with its own operational overhead. Now, if you eliminated that,

and then what does the world look like? Initially, every APM tool had to create this extension, come up with a proper format for application to talk to databases, and you would do it for every engine, write every engine type, post it in different places. And you had this effort, all this effort, just for application to talk to databases by every vendor. Instead, if we all agreed on a common standard, the databases and the application monitoring tools, then you move from spending your energy in

this data collection and proprietary formats to an open format. We all start building tools which are simpler for our customers versus spending energies on the mundane stuff right so i think that's the bigger picture i never saw until sql commenter became popular and i think it's a good step in that direction yeah that's been the the hope and promise and dream of open telemetry right that you especially the idea that if you are a software vendor, like, you know, Google with their databases or let's say, you know, any software package,

you know from the way you develop it, the way you use it, what are the most important performance considerations so that yes, an APM vendor like us can add some trace stuff in there and and pick up the standard stuff but if you're an expert in your area you can package that right into it and then whatever tool supports open telemetry is going to pick up on that and automatically get that and make that performance analysis so much richer with so much less upfront effort so, to me, the fact that you're all going down this path,

I'm sure you're baking it into these databases. So it's like here, it's up, it's running, the data is there for you. Just get it, you know? I think that's the key and that's the bright future of open telemetry, which I think is quite wonderful. Because it's funny because people often ask us like, well, with open telemetry, what does that do to the APM vendors, right? I mean, the telemetry is just a trace, you know?

That's just part of it, right? And then that's what do you do with it, right? And that's the whole other side of it, that, you know, I think there's a very happy symbiosis, whatever, between all that. But, yeah, I'm really excited to start seeing this in the wild because it's, yeah, I haven't seen it yet, so I have ideas of what I might see, but I think it's amazing because developers, there's so much tasked with database these days. It's always, always much, much, much more of a question.

And once again, my heart goes out to developers because not only do they have to write their code code they're starting to be asked to write their monitoring starting to ask to be able to figure out how to analyze their code and do everything else it's becoming a uh an extremely heavy job so hats off to all you developers out there hey nimish closing question. It's 2021. When do you think? I think so, right? Let me just look at my watch.

Yeah, it's 2021. When do you think, when do you think, or how long do you think it will take until this is truly in a place where regardless of what DB I'm using as a developer, I can bet on that I get my distributed trace end-to-end all the way into the database. So from our point of view, we are already doing this, right?

So Cloud SQL Insights, if you see what we launched, you can do this end-to-end. And we are working closely with Dynatrace for the last few months to make sure this experience is also integrated. So we are already seeing this, and we'll see this more in 2022 with tighter integration, even simplifying the journey for the overall ecosystem

is shaping. I think we all have to come together to keep pushing towards a common way, which we are, for example, like OpenDynamic and SQL Commenter. Like most changes, this might be slow, but you'll see more and more vendors and more and more APM tools being able to do this end-to-end tracing with managed data. But I'm excited. We already see this. We launched Cloud SQLl insights early in

january because of this application-centric nature it became one of the most popular and fastest growing capabilities and databases which shows this power and we are looking to collaborate more we have joined customers who are waiting for out of the box cloud sql telemetry inside dynatrace and hopefully we all can make this work soon yeah perfect um well then we endly uh well finally endlich is a german word i wanted to say something in english but then my brain already switched to german because it's late at night here and the beer is already waiting over there exactly uh i want to say thank you so much uh nimesh we will make sure to add the links that you gave us uh some podcasts you did the blog posts the announcements the documentation uh everyone you know please um leverage the fact that you have dedicated teams here at Google,

at Dynatrace and everybody else that is contributing to OpenTelemetry. We are all dedicated to make the world a better place, especially for developers. And give us feedback and let's work together on this. I think this is great. So that finally we can stop the finger pointing between the app guys and the database guys because we're all end-to-end responsible for this. And we have it in our hands.

Let's all join hands, shall we? Yes. No, I think it's just wonderful. All right, well, if anybody has any questions or comments, you can reach us at pure underscore DT on Twitter. Nimesh, do you have any social medias that you would like to share? We can put them in the thing, but anything online or anything verbally? I'm not that active on social.

Okay. You're on Google. What is it, Google Plus? I hope that doesn't get you fired making that joke. Anyway, thank you all for listening once again. And Dimesh, thank you so much for being on. I think this is going to be a great new path forward with this insight. So I'm looking really forward to it. And I am looking for hearing new database problem patterns that we all start picking up on this um if you start coming across new patterns the mesh

please let us know and come back and share with us we love problem patterns especially new ones or even old ones in new ways right so just historically we saw you from three-tier architecture there were certain uh problem patterns patterns, N plus one service calls and all that kind of things. And what we started seeing, at least once people started going to the microservices, were the exact same patterns, just the microservice version of them. So curious to see as we start going to these cloud databases, as people take more control into their own hands, are they just making more complicated versions of the same problems or are new ones cropping up? So anybody starts coming across them, let us know. But Dimesh, obviously, we'd love to have you back on if you have anything on that side. Absolutely. It's been a pleasure. Thanks for having me. I think it's important to tell the story given that we are early in this cycle of this disruption, if I would

say, with cloud and developer being the main person to troubleshoot. So we need to invent, but we need to tell our story and evangelize what we are doing. So thanks for having me and helping me tell this story. All right. Well, thank you very much. Yes. Thank you. Thank you.

Bye-bye. Bye folks. Bye-bye. Bye, folks. Bye.