Overview of Azure HorizonDB

[00:00:00]Hi everyone. In this video, I want to dive into what exactly is Azure Horizon DB.

[00:00:08]Now, if we take a step back, if we think of PostgreSQL, this is a very mature, it is open source, uh relational database. It has super strong capabilities, has a large ecosystem of extensions, of community, has AI capabilities.

[00:00:37]And when I mentioned that word relational database, what's really important about this, what we care about when we leverage it, is it is acid compliant, which means we get a guarantee that it's safe, it's reliable, we get correct transactions.

[00:00:53]If any part of a transaction fails, the entire transaction is rolled back. There can't be any partial updates, which would cause business problems. Hey, I added money to this account, but I didn't remove it from this one. It helps avoid things like corruption. Now, you might be wondering, okay, we're talking about PostgreSQL, I know in Azure, we have the Azure Database for PostgreSQL Flexible Server. Now, that added things like Entra integrated authentication.

[00:01:31]It adds things like the PG vector extension. So, again, there's a number of great extensions to this, but we have PG vector.

[00:01:41]When we think of those embeddings that represent the semantic meaning of data, super useful for AI and natural language.

[00:01:49]There's things that build on top of that, like the disk ANN, which is a better nearest neighbor vector search capability.

[00:02:01]So, that work out there. So, we're doing this good solution in Azure for PostgreSQL.

[00:02:07]And we see PostgreSQL used in large and small applications. However, if we think about from an architecture perspective, Azure or non-Azure, it's really built around this idea that we have a primary, the one that we can read and write from, and it has both the compute and the storage responsibilities. It is not distributed.

[00:02:43]Now, yes, I can technically add a number of standbys or read replicas that have read endpoints. I can go and use them maybe for analytics.

[00:02:57]But, primarily, I'm going to bottleneck my performance on whatever this primary node is. So, and also, when I think about the replication, that's work this primary has to do.

[00:03:13]Now, you may be saying, "Hey, look, I know we have the Citus extension.

[00:03:19]And what the whole point of the Citus extension is it lets us horizontally scale our database."

[00:03:24]Now, what it does is it does that by turning PostgreSQL into a distributed database. So, the data has to be distributed via shards.

[00:03:34]We partition up the data based on this distribution, this sharding column.

[00:03:42]And while that solves the scalability challenge, what it does mean is that when I'm the application, I have to change my app.

[00:03:57]Because I have to think about, okay, I have a distribution key. I have to consider as part of my query design that distribution. So, there's changes I have to make.

[00:04:08]So, then let's think about, okay, we have the cloud.

[00:04:13]And it's very common now to have cloud-native architectures, where we disaggregate, we separate the compute and the storage. That is as independently scale, and also I can take advantage of native capabilities for services that exist in the cloud. For example, if I think about cloud storage service, I think about blob, there's a whole set of capabilities with replication, with snapshots, with backups that exist as part of that service.

[00:04:42]So, the whole goal about this is, great, we have this PostgreSQL database that has a lot of really good things.

[00:04:50]Well, Horizon DB is a cloud-native version of PostgreSQL. So, it is a fork of PostgreSQL. A fork means, hey, we take the code and we essentially take a copy of it, to which we can now make changes.

[00:05:17]And as part of that, it enables that disaggregation of the compute and the storage. So, I can get higher scale, higher performance, higher availability, better security. But, here's the really important part.

[00:05:30]From an API perspective, it is the same.

[00:05:35]So, it's the same API. It is the same PostgreSQL tools that connect. It has a 100% PostgreSQL compatibility.

[00:05:51]So, when I'm thinking about, "Okay, my app and that Okay, I want to go and talk to Horizon DB." There are no changes that I have to make.

[00:06:03]But, as part of that, I'm going to get all of these benefits around that idea of the better scale, performance, and availability.

[00:06:19]So, I get a whole bunch of goodness without breaking anything. So, I get that cloud scale without me as the application developer having to do anything differently. And And that's the whole goal around this.

[00:06:35]So, how does this work? How are we making these changes?

[00:06:39]So, from an architecture perspective, it is still a relational database.

[00:06:47]So, I still have my primary compute.

[00:06:59]So, we're going to separate out the compute and the storage. So, there's only one single primary instance because of that relational database.

[00:07:08]Now, when I think about this, this primary compute, and I think about the interactions, so, the read write endpoint talks to that.

[00:07:24]From a scalability perspective, this can have up to 192 V cores.

[00:07:36]For each V core, I get 8 GB of memory.

[00:07:44]So, it's going to scale linearly.

[00:07:48]So, let's actually take a quick look at what we see when we create one of these.

[00:07:53]So, if I'm creating an Azure Horizon DB instance today, you can pick things like obviously the region, PostgreSQL version, but from a configuration, what we're picking here is the number of V cores, and we get that associated amount of memory. So, that is the primary thing we are selecting, and then by default, it's going to add one replica that will be in a different availability zone. But notice I could scale these all the way up to get 15 replicas in total.

[00:08:32]Now, if we focus back on something we just saw, what's really important about this particular primary?

[00:08:39]Well, it lives within a specific availability zone.

[00:08:46]Now, let's start talking about how some of this um separation, disaggregation is actually working.

[00:08:53]So, the what it's going to do is it's using a database as a log architecture. So, what that means is the compute node sends the transactions for the write-ahead log, the WAL, which is basically the transaction log, to a separate fleet.

[00:09:12]And so, if this is my compute, what we're actually going to have is this separate idea of the write-ahead log storage fleet.

[00:09:33]And this is made up of of lots of different instances distributed across all of the availability zones. So, 1 2 and 3.

[00:09:43]And so, as there are transactions made, what's going to happen here is this primary compute is actually sending them across multiple instances across all three of the AZs. So, it's actually sending it across cross-zone in millisecond time.

[00:10:11]Remember, these are all append-only writes. And the WAL itself is using an NVMe pass-through so it accelerates its performance by skipping layers of the kernel of the IO stack so we get a really, really high performance here.

[00:10:25]And the compute's quorum manager is responsible for sending those across to the different instances, across the different AZs in this WAL storage fleet.

[00:10:37]And it has to have the majority to succeed in the commit for it to consider that transaction to be successful.

[00:10:46]So, this is how we start to see how the compute and the storage are separated across.

[00:10:51]But then what we have is if this is the the write-ahead log storage fleet, we have a second Oh, wrong color. Let's get the color right.

[00:11:04]We have a second data storage fleet.

[00:11:19]Which again is made up of lots and lots of different instances providing the service, which again would be spread over all of the different zones within the region.

[00:11:35]Now, once we have that, what's actually happening here is that this stores the actual data pages. It is transparently sharding the segments, think a chunk of data up to 1 GB across this storage fleet.

[00:11:51]So, any IOPS, any throughput I have is spread across that entire fleet.

[00:12:00]And so, this while storage fleet is responsible to populate the data storage fleet. But, it's going to do it very intelligently.

[00:12:13]It has a filter, so it only sends the changes to the storage nodes that powers the particular data portion.

[00:12:23]And then, the data storage fleet, the node, will reconstruct the data pages by applying the write head log content it has.

[00:12:32]Now, today the maximum database storage size is 128 TB.

[00:12:46]Now, that size is really focused on what they've tested today, what they're supporting today.

[00:12:54]There's not a reason why that's the maximum possible size, and that might change in the future.

[00:12:59]But, it's also going to auto scale. You don't have to manually provision that storage.

[00:13:04]And what's important when you look at this just initially, is realize this means the compute node is not performing any of the storage tasks. They're all offloaded to the storage fleets, which means the compute node can just focus on doing compute stuff, the handling of the transactions. Now, if we jump over for a second, we can actually see some examples of the things that are offloaded. So, these are all savings, if you will, that now that primary compute node does not have to do. So, some of it is disk IO savings, some of it is network savings, but it's offloading those components.

[00:13:47]So, it can focus more of its capability on the actual transaction parts.

[00:13:54]Now, it also means this compute layer is stateless.

[00:14:01]All of the durable content is in this well storage fleet and the data storage fleet.

[00:14:08]Now, this compute layer does also have NVMe SSDs.

[00:14:17]Now, this SSD storage will be multiple times bigger than the amount of memory, which again is based on the ratio of the number of V cores.

[00:14:26]And then, only if from a caching perspective it doesn't hit either what's in memory or what's in the SSD, then it has to go and pull the data from that data storage fleet. So, it will, where required, go and fetch the various pages.

[00:14:45]So, I can think about, hey, nanosecond latency where it's in the memory, microsecond latency where it's in that NVMe storage, millisecond where it is actually a remote read.

[00:14:59]Now, for ultimate durability, what sits under all of this is, as you might guess when I think about storage capabilities, it is using zone redundant blob.

[00:15:15]So, I've got ZRS blob.

[00:15:20]And this is being used both for the write-ahead log and it's being used for the data storage fleet.

[00:15:31]It happens to use block blobs for that append-only well, it's using page blobs as part of the durable storage for the data fleet.

[00:15:42]Because the well storage fleet is only keeping the tail of the log and then any retention requirements are fulfilled uh by the blob.

[00:15:51]And these storage accounts are all Horizon DB instance-specific. There is no sharing across any instances of Horizon DB.

[00:16:01]Database backups are done via snapshots.

[00:16:06]So, backups snapshot.

[00:16:15]Now, as you saw when I showed you the page, you can have standby read replicas.

[00:16:23]So, in addition to my primary computer with its configuration, what I can also add here are n numbers of standby or read replicas.

[00:16:46]These also have those same NVMEs.

[00:16:49]And as mentioned, you can have up to 15 maximum of these.

[00:16:56]And what happens here is there's actually a load balancer that distributes to however many you have. And so, the read-only endpoint is housed on the load balancer, which then will go ahead and send it through. Now, these are actually using the data storage fleet. So, there is no PostgreSQL replication replication involved anywhere. They are all the same config from a compute and memory perspective as the primary.

[00:17:40]And so, if I had those 15 read replicas, that's where I would get the 3,072 V cores you may have seen.

[00:17:48]Now, they also have, as I mentioned, all of those same shared buffers, a local SSD cache. They get those pages sub-millisecond read latency as required. Today, they have to be in the same region as the primary because they are sharing the data storage.

[00:18:06]Now, what's also going to happen because we have this um caching, the write-ahead log fleet will also send transactions to any of those standbys where it's a change to a page that is in memory for that specific replica.

[00:18:30]And obviously, these are also used for high availability purposes. If the primary goes down, it picks the closest replica, makes it primary, and then moves the read-write endpoint to that instance.

[00:18:43]Now, because this write-ahead log storage fleet is the single source of truth, and because these are stateless, when there is a failover, it's really simple.

[00:18:55]You just switch the role holder of the primary, and you move the endpoint, and you're done.

[00:19:03]There is done as a normal PostgreSQL reinitialization task required, so failover is much, much faster.

[00:19:11]Uh I can manually fail over when I want as well.

[00:19:14]GeoHA, I believe will be available at GA. It'll be a separate cluster in another region.

[00:19:22]There'll be a shared virtual endpoint on top to make it transparent. It'll use async replication as you always do anytime you're multi-region.

[00:19:32]So, this is the architecture. You can see where it's separating that compute and the storage. You can get these really high performance, this really high scale, and these really nice availability capabilities.

[00:19:43]Now, for my other feature capabilities, we sort of talked about some of the things we have already.

[00:19:49]So, when I think about Horizon DB, it it's going to have that same Entra ID integrated authentication.

[00:19:57]There will be private endpoint supported. It currently supports 75 of the most popular PostgreSQL SQL extensions. They're working on more. So, you think about things like that, disk ANN, BM25 for rich text searching and ranking.

[00:20:13]Um it can mirror to Microsoft Fabric.

[00:20:16]So, if you think of Fabric as that data virtualization layer, all these different engines that can operate on the data, I want to expose ontologies, um semantic models of my enterprise entities referring to data, hey, Horizon DB can take part of that.

[00:20:33]There are AI pipelines. I can describe um the AI workflow using SQL. So, it's the declarative. So, chunking, embedding, uh the generation, the ranking, all of that, I can run that as a fault-tolerant pipeline. It's going to live inside a PG durable um function.

[00:20:54]It has model management. So, when I think about doing things like creating those embeddings that represent the semantic meaning, well, I need AI models for that. It would do the model management for you. So, it would integrate with Microsoft Foundry.

[00:21:09]And so, when I think about embeddings, chat completions, and re-ranking, they will just be available. Yes, you can bring your own if you want to, but it will also just take care of that if you want.

[00:21:22]Now, from a pricing perspective, we're paying for the compute instances.

[00:21:31]You're going to pay for the optional standbys.

[00:21:36]You're going to pay for the size of the database.

[00:21:43]And then, you're going to pay for these backups.

[00:21:47]So, those are your cost dimensions.

[00:21:49]There isn't a separate IOPS or throughput price. It's baked into the cost of the database storage.

[00:21:56]Now, if we jump over and actually look at the pricing page, you can see it talks It kind of showed that as we create, but you pay for the number of vCPUs, which obviously includes the amount of memory.

[00:22:09]And then, I pay for the amount of storage the database, and I pay for the amount of backup. And then, I would pay for whatever the cost of the Foundry model. So, if it's managing the models, it doesn't charge you an additional cost for managing them, but you would still be paying for the Foundry cost of whatever models it goes and creates to do that management.

[00:22:32]Now, something you do have to consider when you think about the pricing is sizing the environment correctly.

[00:22:39]Because think about it now. There's There's one copy of the data.

[00:22:44]So, when I think about There's one copy. I'm not having separate copies across, for example, different replicas.

[00:22:53]Remember, it's offloading a lot of tasks now to these storage fleets. So, more of the vCPUs, more of the memory in the compute instances can just go to doing the work.

[00:23:05]So, when you think about sizing it, don't just think, "Hey, my PostgreSQL instance is this size today, this number of cores, this amount of memory. I need the same for HorizonDB." It might be you can have smaller instances, but achieve the same amount of performance. You're going to want to pay attention to that as part of that exercise.

[00:23:22]And so, that was it. I really just wanted to talk about what it was. So, HorizonDB it is a cloud native 100% PostgreSQL compatible database, but because of that cloud native architecture, it's solving many of the scale, the performance, the availability challenges we normally see.

[00:23:42]Now, this is early days. It is in preview. I would keep an eye on documentation as more features will get added as it gets closer to GA, as it hits GA, then past GA.

[00:23:54]For now, you're not going to want to use this in production. It's preview.

[00:23:58]You could definitely start experimenting and then think about where it may fit in your architectures, especially where you are seeing challenges today, as you think about that scale, the performance, the availability, and this may well be your solution.

[00:24:12]Hope that's useful. Till the next video, take care.