 Okay, finally we are ready. Okay, then let me first start this. Welcome to this session. This session is for open source DB Azure service on the top of Azure. And then this is a kind of workshop. So then we will work through on overview on open source database Azure service on Azure by Brian. And then I will explain how you can do your own workshop in 10 to 15 minutes. And then let me briefly introduce Brian again. So Brian works at Microsoft in GBB. GBB stands for Global Blackbird, which is one of very special teams in Microsoft who are specialized in specific technologies. And Brian is an expert on open source databases. So that's why I am now having presentation with him. So thank you Brian for your time for today's session. And then he will explain overview on open source database Azure service. So I will hand over to him. Thank you Brian. Thank you Ian. And thanks everyone for joining today. I'm in Brisbane, Australia. So it's one o'clock in the afternoon, just after. So good morning or good afternoon to you, wherever you are. And as Ian spoke about there, today I'm gonna walk you through our open source relational databases on Azure and give you an overview of the platform features, the how, the why, the where, and the when. And then hopefully that sparks some ideas in your head about how you could take advantage of some of these services and make your life easier as a developer or whatever it might be that your job entails. So if you have any questions, please put them in the chat window and we'll try to get to those at the end. And so we'll leave some time at the end for Q&A, but yeah, feel free to pop a question in there if you have one. Okay. Alrighty, so I think just to sort of set the scene, we see a lot of shift in momentum towards open source databases. And this is backed up by the usual sort of, the analyst firms. So to set the scene from a relational database point of view, we see great growth in Postgres and MySQL particularly. And those are the most used databases by professional developers. So in conjunction with that, we see a lot of talk around new applications being developed and Gartner in fact, reckons that by this year, 70% of new enhanced developed applications will be developed on an open source database. So that's a pretty exciting number. And it clearly shows you that there is a growing trend towards open technologies, not only in front end development or APIs or whatever it might be, but databases as well. And also Gartner follows that up by saying that by 2023, 75% of all databases will be running in the cloud. So that's another interesting prediction by them. So that's some serious numbers if you think about the number of worldwide databases. And of course, as many of you are not aware, Postgres and MySQL continue to win awards for databases of the year. So you're not alone in choosing these technologies that you choose to do. So there's healthy communities and innovation in all aspects of these databases. Now I might use the term Dbass in this session. And essentially that's databases as a service. So it's kind of like platform as a service, but we specifically call it Dbass. And what is Dbass? Well, you might think about the sort of three levels of where you can run databases. And this picture here shows you that on the left, we've got a non-premises stack, if you like. And in the middle, it's IS or VMs, essentially. And then on the right, we have the Dbass or Pass option. So what this highlights is, is how much responsibility there is on a developer or a user for the operational tasks. So on the left in the on-premises column, you can see that if you want to stand a database up in a non-premises scenario, you can pretty much be responsible, maybe not you, but the organization for everything from a data center all the way up to protecting your data and everything in between, including hypervisors and hardware and networking and database provisioning and patching and high availability, disaster recovery and so on. As you move to the right, if you take advantage of VMs or IS, your responsibility shrinks a little bit. It's less about hardware and data centers, but you're still responsible for everything, typically from the operating system up. When you move to Dbass, then that shrinks significantly because not only is it about the platform being managing hardware for you, but we also manage the underlying operating system, which a lot of time you don't actually know it's there. The database provisioning, the patching, the security, the set up of daily backups, all that operational tasks. What's left are applications in data and that's the sweet spot. And I'm sure that's where many of our people on this presentation today are living that area. So what you can do with these Dbass offerings is minimize the amount of effort you have to stand up, to maintain, to back up, to make available, to secure your data. And of course, that frees you up to do more with your applications. And that's generally where the value is. Okay, and I'll touch on the support in a second, all right. So in terms of an overview, all of our databases are fully managed and in line with those diagrams that I showed there. We use the community versions of MySQL, MariaDB and Postgres, so we're not forking. We're not turning into something that might be incompatible with where you want to go in the future. We handle the support and the liaison with those upstream open source community projects. So if there's an issue with MySQL or Postgres, you don't have to go and start to communicate with the community, you raise a ticket with us and we'll do that on your behalf. So it really is a single point of contact for everything. These databases also integrate with the rest of Azure, especially the data ecosystem. And that's in line with their commercial offerings. And of course, we're trying to make these developer friendly so that developers can stand up, migrate, integrate all of their applications and their solutions with the rest of Azure and take advantage of that ecosystem. At a high level, what are the services of the DBAS? So essentially scalability, so you can scale up and down, compute, storage, et cetera. We provide inbuilt monitoring so you can set up alerts and integrate with third party tooling to do notifications or use platform notifications. We also provide backup and restore that part of the service. We have simple configuration to get high availability and disaster recovery options. We do that minor version patching for you, so that's not something that you have to take care of yourself if you deploy. Major version upgrades, that's customer managed at this stage. We also have tools for migrating from anywhere into Azure DBAS for our open source offerings. And as I touched on, we have the integration with the rest of the Azure data ecosystem and we provide tools for provisioning and automation of services so that you can sort of infrastructure that's code type scenarios can be catered for. Okay, this slide shows you a sort of pictorial summary of that, fully managed. We've got intelligent performance built in. We've got the scale, the availability, control from a configuration perspective. They're all open source. Postgres and MySQL are bulletproof open source databases that grew up in the cloud. So that's no different here. And obviously there's a rich feature set across all of those offerings. Okay, now what I'll do, I'll just touch on some of the deployment options we have because there's a few for each different type of database. So for Postgres, we'll start with Postgres. For Postgres, we have four deployment options and we'll start on the right here. We have single server, which is a cost-optimized sort of developer entry level SKU comes with built-in high availability and all of those features we spoke about up front. And it's a single noted database. So you can scale it up to the maximum number of core for a VM, which today is 64. Once you reach that 64 core limit and you're starting to push that limit, then you've maybe got another choice to make in terms of whether you try and scale out or you might look at flexible server, which is also a single noted database. That's the one on the top there. However, it's kind of like the new improved Postgres on Azure. So it now runs Linux as opposed to Windows on the single server version, which gives us more performance and it also has some better performance as a result of a refresh of the hardware that underpins that service. We have enterprise zone redundant high availability, which I'll talk about in later slides, more exposure of the kernel parameter, sorry, the database engine parameter to the user to tune for varied workloads. And we have a custom maintenance window that allows you to find fine grain control when the platform maintenance is scheduled. We also then going to the left, we also have hyperscale cytos, which is Postgres on steroids. It essentially allows you to scale out Postgres. Now, this is using a open source extension to Postgres, Postgres being an extensible database. The cytos extension is exactly that. It is an extension that you can enable in Postgres and it will then shard or distribute whatever tables that you might want across multiple nodes in a cluster. Now, the beauty of this is that it's still Postgres. So there's very little application rewrite that is needed to take advantage of the scale like capability. I'll touch on that in some later slides. And lastly, we have hyperscale on up, which is the ability to run hyperscale in Kubernetes containers. So you could run them on AKS, you could run them in EKS, or you could run them on prem. And that gives you a bit of a hybrid approach to running database, or Azure Postgres bits anywhere. Okay. Now, in terms of the use cases that we see around certainly this region, but globally, we see modern transactional applications built with, for example, AKS hosting applications. And there's an example there of the Finnext offering or the application. We see real-time operational analytics, which is another really good use case for Postgres and a particular hyperscale. We see geospatial applications using PostGIS, which again is another extension to PostGIS that allows you to tap into geospatial capabilities inside the relational database. We see time series data, especially when you've got large volumes of time series data, we can, PostGIS has partitioning as an option, which really helps in those sorts of scenarios. And we also see a lot of organizations choosing to modernize and move away from on-prem or legacy databases such as Oracle and modernize those apps and the data layer to take advantage of these open source technologies. Now, moving on to MySQL and MariaDB, obviously these two need no real introduction. MariaDB is essentially the open continuation of MySQL since MySQL was acquired by Oracle. And as we touched on before, there's a healthy interest and community around MySQL. It powers a lot of internet websites. A lot of the household names use MySQL databases for their underlying data stores, nine out of 10 top websites worldwide are powered by MySQL. And that's pretty impressive. And it's optimized for OLTP websites. However, we see it deployed in many different scenarios. And you might be familiar with the LAMP stack, which obviously MySQL was the, excuse me, was the original database when LAMP became a common term. Okay, now in terms of MySQL, there's only two deployment options. So Postgres has four, MySQL has two. And those two are single server and flexible server. Now, single server, same as for Postgres, it's kind of entry-level, cost-optimized, single node. Flexible server, similar to Postgres, has Linux under the better performance, new features, and extra performance as a result of that. Just before I move on, MariaDB, we only have single server for MariaDB today. The numbers of people that use MySQL on our platform over MariaDB is quite significant. So I don't think that flexible server from MariaDB is something that will happen short to medium term, but watch this space. So for MySQL databases, what sort of use cases do we see? Well, for single server, obviously we've got a lot of happy customers on single server. I mentioned that it's got entry-level and cost-optimized, has high availability built in for free. So that's quite a compelling part of the single server use case. Now we see, again, we see online web applications, workloads that don't need the zone redundancy is another one, so if you just want the best sort of bang for buck, that can be something for single server. A lot of cloud-native applications taking advantage of single server. Flexible server tends to be more about mission-critical applications that you can protect the zone redundant, high availability, and there's more performance to be had there. So, yeah, those are some of the use cases that we see there for MySQL. Now, what is flexible server? So I touched on the single server, which has been on the platform since 2019. And flexible server was GA in November of last year at Ignite, and as I touched on, it has performance enhancements, and I'll talk about these in the next slide. It has the option of zone redundant, high availability, which can protect your workloads across availability zones on the Azure Cloud. We have same zone, high availability. You can add IOPS to a workload to get more performance. So you might have a small amount of data, but you need a lot of storage performance, and you can do that now on MySQL. We have that custom maintenance window, newer versions of MySQL database engine itself, we've exposed more of those configuration parameters to the user, and we've got private access through VNet integration, which allows you to not expose your services to an internet-facing IP address. How did we get those performance improvements in flexible server for MySQL? Well, we moved to Linux number one, so we went from container on Windows to a dedicated VM on Linux, and these databases grew up on Linux, so no surprise that they perform better on Linux than they do on Windows in most cases. We've upgraded the storage stack, so that, sorry, yeah, we've upgraded the storage stack so that all of the underlying storage is now premium storage. We've also removed the gateway now, you might not be familiar with this, but in single server, when your application, like in this diagram, when it connects to your database service, which is a container, it talks indirectly through a gateway, it's like transparent, but it has the effect of adding latency to database traffic. So we've removed that with flexible server, and you now talk directly to your database. So for to your VM, so for workloads that are latency sensitive, that's proven to be quite significant in terms of performance there. As a touchstone, we've got that additional IOPS capability, and we've also got the capability to use thread pools to manage a higher load of concurrent transactions. Alrighty, now moving on to Postgres Flexible Server, again, GAID 2021, similar performance enhancements, we've got that zone redundant high availability across both MySQL and Postgres, same custom maintenance window. We've added platform-managed connection pooling to Flexible Server, and previously on single server, you had to manage that yourself, you either stood up in a container or a VM and installed a connection pooler like PG BANSA, for example. That's now baked into the service, and it's simply a case of changing the port number on your connection string, and you'll be taking advantage of connection pooling and high concurrent user capability. We've also got newer versions of Postgres, so we now support 12 and 13 on Flexible Server, where a single server tops out at 11, and there are no plans to go beyond 11 on single server. So really, I would strongly recommend if you want to deploy Postgres on Azure, that you strongly consider Flexible Server before deploying on single server. And again, the same sort of thing as with MySQL, more configuration of the database, from a parameter perspective, and private access through vNet integration. Similar sorts of things here in terms of performance, to get those performance improvements, Linux as the underlying OS, the gateway is being removed, the premium storage. We've also got V4 compute on Flexible Server, which is a significant performance uplift. You can actually take advantage of local SSDs to case read data. So sometimes that can benefit of certain type of workload. The PG Banser can also be considered a performance improvement because you can scale more concurrent usage. And as I touched on, Postgres 12 and 13 will offer more performance than Postgres 11, just due to the performance features or the enhancements they have made as part of the community releases of Postgres. Okay, so the Flexible Server architecture works like this. It's like I said, it's a Linux VM with premium storage, backups go to zone redundant backup storage. There are three copies of disk in an availability zone. That's a non-high availability solution there. But what you can do is you can with zone redundant high availability, protect that data. And what we do is we actually synchronously replicate across two availability zones. What this does is it guarantees that there's zero data loss in the event of an issue with your primary availability zone. So we stand up a standby in an alternate availability zone and synchronously ship transactions to that, protecting your workload. And we guarantee that with an RPO of zero. So zero data loss in the event of a failure. And the platform manages the failover and typically that is less than two minutes. So from detection of failure of the primary to promotion of the standby to be the new primary is often less than two minutes. So that's really good from a mission critical application perspective. And that's the same across Postgres and on MySQL. One feature that we have on MySQL today that's coming to Postgres is same zone high availability. Now this is the most performant because the latency to replicate between two servers in the same availability zone is less than across availability zones. So it's essentially the same architecture but the primary and the standby are in the same zone. So obviously if you lose the zone then you need to fall to your DR solution but the performance will be better. Okay, now what I'd like to touch on is our hyperscale offering. And as I mentioned in the deployment options hyperscale is a scale out solution for Postgres and how it works is in line with this diagram. The cluster is made up of one coordinator and any number of workers. Now we've got customers who have hundreds of worker nodes. Now each one of those worker nodes has its own dedicated compute and storage. And so what that allows you to do is get near linear performance increases as you add worker nodes to your cluster. The coordinator node is the connection point for all applications. And so applications don't know that they're talking about the distributed Postgres apologies for the dog barking. What happens is as the queries come in to the coordinator node, those queries are distributed across all of the underlying worker nodes. And in parallel results get aggregated and returned to the coordinator. I think I got that slide the wrong way around so bear with me. So how do we distribute the data in hyperscale is it's charted or partitioned if you like across separate worker nodes. What happens is when you choose to distribute a table and it's at the table level behind the scenes, the Citus extension will distribute that table to the worker nodes. So it will spread it much like this example here where we have a customer table. It will spread shards across the underlying worker nodes. When queries come in to those worker nodes, then this is when the query is distributed and split across however many worker nodes around the cluster. And that results in significant performance due to the NPP architecture. Now it's all DML and EDL is distributed. So when the coordinator issues a command that can that will be sent to all the worker nodes and the coordinator keeps track of the ranges of data that live on each worker node. And it's all transparent to the application. They're just talking to a post-gres database. Okay, we also do shard rebalancing. So if you add a new node to the cluster to scale out to add more performance, we have a feature that allows the data to be sharded across all of the nodes in the cluster. And it effectively does that by moving data between all of the workers and rebalancing so that you don't get hotspots on a particular worker node. Now this is non-disruptive. So you can actually add compute and storage and performance to the cluster non-disruptively. Okay, now hyperscale has, it's very similar to flexible server. There's actually a couple of nice things about it. One is we have a single node cluster available. It's called the basic tier. That combines the worker and coordinator into a single node and allows you to test and develop and take advantage and figure out how it works and how you can make your application take advantage of that. And then you can scale that single node out to be a multi-node once you want it to go live or if you wanted to test more scale. We've also got newer versions of Postgres including Postgres 14. You can do a major version upgrade in the portal. So if you are on 13 and you want to go to 14, you can click a button to do that. Now I would advise testing that in a non-production environment before you do that. Now we've got the shard rebalancer. We've also got columnar compression. If you highlight that, take a picture of that QR code and it'll take you to an article explaining how columnar compression works. We have read replicas. We have that inbuilt connection pooling, the custom maintenance window. It sounds the same as flex, like I said. You can change sharp keys on the fly which you couldn't do in the old version. And we've also got a distributed meta data option which if you grab that QR code, you should be able to figure out that that's a pretty cool feature where you can actually talk directly to any node in the cluster. Okay, I think I'm at time. So hopefully that was very useful to explain to you what open source database options we have on Azure. And I'll hand back to Ian and I'll go and see if there's any questions in the chat. Yeah, thanks a lot, Brian, for your wonderful talk. And then there are several questions. So yeah, I can also continue my session. Why then, yeah, it'll be great if you go to share the notes so that you can see the list of questions and then comment for some of the questions. Well, I total, so three questions, but for the last question, then I need to prepare my session. So I couldn't answer, but hopefully then you can answer the final question. So meanwhile, then let me share my screen. So, okay. Mm-hmm, yeah, screen sharing is always not easy. Yeah, I think I'm ready to share my screen. So, yeah, I think everyone can see my screen, right? Brian, then would you double check? It's beginning to appear as we speak. Yes, we've got it. Never get an exercise, always has error, yep. Yeah, thank you for double checking. So my name is Ian, then I'm a developer program marketing manager based in Korea, and then I am working with many developer communities in Korea and other Asia-Pacific countries. And then yeah, I would like to elaborate how you can navigate and exercise open source databases with Microsoft law. So then yeah, you can click this URL. So URL is aka.ms slash learn OSS DB as your service dash for Asia 2012, 22, but the URL is a little bit long. So you can just take a screenshot here or then you can use this QR code. And then yeah, I will share this URL later or then hopefully you can see this URL later. And then once you click the URL and then you should go to this page. Actually, and then if you go to the URL, if you go to URL and then you would see that there are a number of resources. For example, let me click this URL. And then yeah, I collected a series of Microsoft long modules which are super great for you to more explore on open source databases as a service on Azure, not only for MySQL and PostgreSQL, Brian mentioned, but also there are great solutions like MariaDB and also then Brian mentioned hyperscale she does on open source database for PostgreSQL. And also then I think several other things are for developers so that you can also elaborate how to integrate PostgreSQL into your applications like Node.js or any other kind of applications. So let me click this MS long module because then it is really easy for you to experience a PostgreSQL on Azure for free, even for free. And also then all the detailed instructions and explanations are here. So then Brian kind of explained very details but if you want to see read rather than listen to Brian presentation again and then you just go through this MS run module. And then if you click this exercise and then yeah, you should see this kind of screen once you log on on MS run. And then yeah, this launches a separate laboratory for free so that anyone can experience this for you to experience how you deploy PostgreSQL database server to Azure and then how you can use. So I clicked launch lab and then yeah, you will see definitely to see the lab will launch in a new window and then if you click start lab and then such kind of separate window will be shown. So once you see this you are there I already log on but however then there is a resources tab. So then your first you will see a username and password screen on Windows server. So then you can just click this to type username and then click this for password. After then and then you can, you definitely can see the same instruction as exercise on Microsoft log. For example, then when I go to exercise again and then yeah, the instruction is same as a database administrator and then connect to the lab environment or and so on. All the instructions are the same on the right side. So then you can read and then experiment. So the first instruction is to go to Azure portal so I can click this edge browser and then it automatically goes to actually Azure portal. And then I already logged on but however then if you see login screen then you can just click this resources and then you can click username and password to log on Azure portal. And then you can just follow the instruction for example, then you can go to resources and you can type password and also then you can deploy for square SQL database by clicking create a resource and then you can navigate a number of Azure services but you can search Postgre SQL and then enter. And then yeah, such result will be shown and then you can create Azure database for Postgre SQL and then yeah, you can click create. And just one note is that this laboratory is for your skilling purpose or your deploy experience purpose. So then it encourages you to click single server basic space then flex server, server but then you can join on Azure portal and then you can also experience flex server later. So then let me click single server and then yeah, I will create single server so I'll click and then for resource group and then yeah, it shows a default resource group but however, then time can flow and change so that yeah, you can click just a default resource group which is already created on Azure portal. And then yeah, you can put server name like Postgre SQL Azure and in your name yeah, Post Asia like that. And then yeah, you can leave this as default. Yeah, actually the manual MS learn seems to be a little bit old but however, then Postgre SQL open source database is being upgraded so then you can definitely click version 11. But for competent storage, please click configure plus server and then you can change to basic and also then you can change just CPU record to one. And I saw some questions on that why Brian was presenting. So then yeah, how the question was how many databases you can create actually then there is no limit. It is just a limit on Postgre SQL but however, then for storage it will record and there will be some additional digital restrictions due to considering the size of server on Azure. And also then you can click and then yeah, you can type lab admin and password like that. And also then you can click just to leave and create and then you can create and then yeah, the resource will be deployed. So then after then you can test this Postgre SQL and then yeah, it is really quick while then I can also briefly explain how you can experience this Postgre SQL. Actually then on this virtual machine, there is a very useful tool called this is Azure Data Studio Tool. You should see that this is something similar as Visual Studio Code. It's right because then it is built using Visual Studio Code open source but anyway then using this then you can connect to Postgre SQL Database once it is deployed. Why then one issue would be that you need to enable connectivity to connect from this Azure Data Studio to Postgre SQL because to connect to Postgre SQL you require an additional network connection. So, but database connection should be managed with high level of security. So yeah, to do this and it might take some time. Ideally it should be deployed very quick but usually then it takes one or two minutes within one or two minutes. So let's see then once it is deployed then you can just go to the deployed Postgre SQL server resource and then select allow access to SQL services and setting yes and then add this client IP which is the client IP should be a virtual machine you are trying. And then you can connect to this database with the password you put and then you can test your query. So then hope that you can experience Postgre SQL if you are not familiar. Also then if you are not familiar on Azure and then this instruction is really self-explanatory so that you can just read and follow and then on the right side and then you should experience other things. So let's wait a little bit more. So yeah, it takes a little bit longer than I usually I expected. But anyway then yeah, also then this for Azure's data studio and then you should see the left side on some menus. So then once you click this connection and then once the Postgre SQL on Azure is successfully deployed and then you can just add the connection. And also then yeah, this kind of a problem menu on usual Visual Studio should work. So yeah, it is also a open source so that you can search on GitHub slash Microsoft slash Azure Data Studio and then you can see this repository since it is also based on based in open source. So then you can also download and execute or then you can contribute to enhance this Azure Data Studio. And currently then it supports Microsoft SQL Server and PostgreSQL. But yeah, hopefully then there will be more contributions and then yeah, more database connection will be supported in future. So meanwhile then oh, it's still deployment. Oh yeah, deployment is complete. So let's go to the resource and then yeah, this is a server name. So I can copy and also I can paste here. But as I mentioned, and then you should enable connection on connection security, then you should add this client IP address for this virtual machine. So I will click this and then I will also click allow access to Azure services for so that other Azure services can connect to this database. So yeah, this is important because without this and then other Azure services cannot connect this PostgreSQL SQL single server. So and save and then it should work very quickly. And then once it is done and then let me go to this site and then also that I pasted the server address. And then yeah, user name is yeah. Let me also copy and paste. Yeah, the setting was applied. So I can go to overview. And then I will use admin username right now and then just like to create and paste and password. Yeah, and then yeah, I will leave database name and address as default and then I will click connect. Okay, the connection was successfully managed and then yeah, I can create database and then I can see a default three databases and then I will just click PostgreSQL database and then it also supports a kind of notebook format if you are familiar with Python and then it is very similar as Jupyter notebook. So then you can execute a query like select from information data, schema data and SQL features. Yeah, let's let me execute this query and then elect to learn cells and then yeah, it should run. Okay, yeah, the query is successfully executed. Yeah, it is managed a kind of separate notebook. So you can save and manage a number of queries separately. This feature seems super great because most developers are now familiar, especially for Python open source contributors are very familiar with Jupyter notebook format. So then yeah, you can manage a number of queries and then your own execution through this notebook. So yeah, this once you finish the exercise and then you can click Done and then yeah, let me complete and then it goes back to Microsoft Run then you can answer the page. So then hopefully you can answer all the pages and then once you're there, once you finish and then you can unlock this module so then you can complete this module like this and then on cloud skill challenge there are a number of great modules provided. So you can also experience other great Microsoft Run modules and for today then I just focused on how you experience post-classical on Azure on MS Run. And then hope that my session is useful and yeah, this is the end of our session. And so hopefully then you can more learn and explore and your own learning path with Microsoft Run. And then, okay, and then I'm now going back to the present mode and then yeah, Brian, are you there or yeah? Yes, I'm still here. Yeah, great, great. So now then each hour 28 times. So I'm wondering then would you want to comment from some of great questions? Yeah, look, I've answered most of the questions along with you Ian in the chat. I don't see any unanswered ones there but does anybody have any further questions? I think there was a, for that first question Ian had suggested that you might wish to comment, Brian. Okay, so how many databases that one? Yeah. Yes, yes, Brian. Yeah, okay, so looks that there's no real practical limit. Are you talking about, if you're talking about instances that you can spin up as many instances as you want but within an instance or a service you can also create databases like in Postgres you can create a hundred databases or a thousand databases. Really what the limitation is is the amount of storage underneath. You could spin up as many as you wanted. Same for MySQL, you can create databases or schemas and there's no real sort of practical limit. But yeah, so I think you only pay for the one service. So if you start by putting databases in that it's still the same cost, sorry. I've never tried pushing either database towards its limits but I assume at least in my experience the problem has been as much the provisioned IO capacity and the provisioned CPU and RAM as it has the total amount of storage provision. But yeah, I've never seen a reason to say you can't make more databases and I always think more databases or more tables whatever. I think we had a customer who asked about more than a thousand a couple of weeks ago and the response was yes, you can do it. I mean, obviously you'll reach a point where you, like you're alluding to their role and you might reach a point where it stops working from a capacity point of view. The other thing I would say is a best practice rather than for example, having a single 16 core database instance, it might actually and sometimes be better to have two eight cores and maybe have like test and dev on one and prod on another. And the reason for that is obviously you get that separation of compute, you get independent storage. You also get backups at the entire instance level or the service level. So if you wanna do a restore, you'll end up restoring all of your data even if you only need a little part of it. So things like that and to avoid the noisy neighbor syndrome where you've got a dev database inside an instance along with prod and somebody's trying some new code, writing some queries and that query uses a lot of resources, whether it's IO band with their compute, that might negatively impact the neighbor. So there's not really a good reason to put too many inside a service, but obviously depends on your use case and just be aware of the potential pitfalls I would say. What's, so that's extremely the other way. I may absolutely accept the scaling out horizontally does automatically limit the potential for one poorly optimized query to flat line the service for a thousand other clients. What are the upper limits? This is more for a question for analytic workloads than for transactional, which I admit is not perhaps what Postgres and MySQL are best for, but what are the upper limits in terms of core counts, memory counts and IO per second? So when you're talking about scaling out Roland, that's the hardest thing. Scaling up, what are the limits for scaling up? Okay, so today it's 64 cores on both Postgres and MySQL flexible server. MySQL will have 80 cores available within the next quarter. And in terms of storage, they're limited to 16 terabytes today and 20,000 IOPS. And RAM? RAM is kind of like linked at sort of like five, five gigabytes per core roughly. So if you have a 64 core Postgres memory optimized, then that'll be almost half a terabyte of RAM. So it'd be 504 gigabytes, I think. So pretty hefty. I mean, I don't see a lot of customers who actually use more than 64 cores. There are very few workloads that would be challenging that. And frankly, if you're working at that scale, you start applying big data principles anyway and you chop into smaller pieces. Exactly, it's something I would have touched on in the presentation, but it's obviously I had to get it into 30 minutes was that hyperscale actually has an HTAP capability. Given that scale outnature of hyperscale cytos, you can actually run HTAP hybrid transactional and analytical processing on the same dataset. Because you've got an MPP cluster, you no longer have to worry about a large query affecting all of your compute resource. So what we've got a lot of customers who combine that sort of OLTP and reporting or analytics on the same data store. Now, one of the real benefits of that is that you can get away with that ETL. You know, like you're doing ETL. I've commercially, I have reason to do this where the ratio between sort of loading activities and query activities is unusual and consequently avoiding ETL into some sort of warehouse is desirable, but it's either at our scale, you know, it's eight cores, 16 cores maybe. You know, the idea that we'd get towards half a chair by the round and 64 cores or 80 cores is not, not something we normally see. So I think it's a useful capacity to have, but it's, if you're getting, if you started to touch the edges, then that's probably a sort of clue that maybe it's worth. Yeah, yeah, yeah, from, yeah, great. From what I was saying, then I would like to comment that still then I see that many customers in Korea and also the other Asia Pacific countries are using on-premise open source database by installing by themselves. But in reality, then managing such open source databases is not easy. Installing is too short. Life is too short. I would much prefer outsourced if somebody's automated it. I have no interest in paying administrators to do that stuff on a sort of custom basis. That it makes no economic sense at all. So no, I, you know, the fact that I can go to Azure and pay for an hour's use of a thing that I would never be willing to build. I, that's fantastic. I have no, there's nothing to sell there. There was one other really interesting question here. And I acknowledge that we're now probably going to step outside of strictly OSS, but it's perhaps of interest to others in the room. So we'll expand a little on a good EAPS question. Are there any, call it serverless or sort of paper query type database offerings on Azure? Yes, so from a relational OSS point of view, there aren't, but that may be coming. However, Cosmos DB does have a serverless option. So that's obviously a no SQL database. But it's, and that's, you know, they scale more sensibly. So that's sort of to be expected. So it's actually a pros and cons. Yeah, there are a number of databases solutions. So then, yeah, these open source databases currently available on Azure are for the open source database users, previous users like MySQL or Postgre SQL servers. And also the flex server server is really great because then yeah, you can also remove some kind of mind share on, you should also manage a number of cores but a core limits like that. So yeah, this is also great. And so I'm also have been using Cosmos DB or for serverless. And then yeah, it is a kind of some mind share difference between when you think on database and also then yes, like three tier architecture on web server or some middle area database and also then serverless architecture. So hopefully then yeah, more audiences can experience more on serverless architecture with Cosmos DB, which is also super great. I mean, the same shift in thinking has had to occur for serverless app containers anyway. It's, you know, you're thinking about the problem in a different way to switch to a serverless mindset. I note that PostgreSQL MySQL haven't gone there yet. So it's the fact that it's not just Microsoft. Obviously, there are other past providers or the best providers who are, whose product lines end up with very similar characteristics that there's a sort of service like option that is not open relational. So it's, I just wanted to expand sort of good answer to say, there is a way to do it. Just sadly and at present and embarrassingly, it's not available in open source. So that was the, but it is available from a zero. If it develops in that situation, where that's the right way to move forward, then it might often be an acceptable compromise to have all of the stack open except for a serverless database engine, which is not so long as non-relational or NoSQL is acceptable. That's, that seems to have- So recently she, although last question, and where can we best use post-grad database better than other RGBMS? Yeah, Brian mentioned their great answers like OLTP, HTTP, also others. But I also would like to point that, in reality, then there are a number of RGBMS users for who are, who have been using my course of SQL server. We are usually say MS SQL, and which is based on key SQL. And also then some users are still using Oracle database. And then yeah, those that they are, their skills are very accustomed. So then for the users on Oracle database, and then they are exploring also the post-grad SQL database there, which is supported on production, but why then they are working with management issues on open source database. So then for those users, then they are considering post-grad SQL database very well. And then I also saw then some customers moved from Oracle database into a post-grad SQL database. So hope that such kind of insight is also useful. Yeah, that's an interesting money. And one of the key things, one of the key sort of factors in that migration from Oracle to post-grad is that the procedural languages are very similar. So if you have a lot of PL SQL code, that transforms fairly readily to PLPG SQL. And so that can de-risk migrations because it can be a simpler migration. And there's a familiarity from a developer perspective as well. So I mean, when you look at the TCO of post-grad versus pretty much any commercial database, it's a huge difference to the bottom line. And that's driving a lot of the adoption. Plus, people don't want to be locked in. I think that's the key trend is people, well, I don't want to go into another service. That means I'm in the same position. Yeah, thank you. Yeah, thank you. That's why we're here. Guys, thank you very much. That was interesting and informative. So thank you for your great moderation. Okay, especially.