Choose the Right Azure Infrastructure to Improve Postgres Performance by Over 60% | POSETTE 2026

Key Takeaways

Hey everyone, my name's Andrew Ruffin and I'm a product manager at AMD. This talk is about the Azure infrastructure choices you have and how that choice can improve your PostgreSQL performance by over 60% including the economics you care about day in and day out. This talk is best for database administrators or IT decision makers who are looking to optimize their cloud footprint when it comes to PostgreSQL. So in my day-to-day, I focus on launching and growing new infrastructure and service options based on AMD technology with Microsoft Azure. So let's go ahead and figure out how to choose the right infrastructure on Azure to improve PostgreSQL performance by over 60%. If you're not familiar with AMD, we're a major hardware and software provider across all areas of compute. And in the data center where Azure is a leader, we provide primarily epic CPUs, Instinct GPUs, Radeon Pro GPUs, and a range of networking and custom products that tie everything together in the back end. So you as a cloud user don't typically need to worry so much about the hardware. Azure does that for you for the most part. But it's good to understand why underlying infrastructure matters and where you do have a choice, where you or why you'd want to consider the AMD option to optimize your cloud costs and performance for PostgreSQL. The Azure and AMD partnership goes back nearly 10 years now. And we launched epic in the cloud with our first generation product announced in 2017 powering what's called the LSv2 storage optimized virtual machine or VM. Since then we've executed year after year, now with nearly 60 different VM series or over 60 VM series, and Azure has also launched uh AMD's first AI focused accelerator, the MI300X, first in the cloud. So we're aiming for a similar trajectory there as what as what we've seen with epic. With VMs covering just about every area of compute you might need uh you might need in the cloud, we need several talks to uh cover it all, but we'll focus on the areas that matter most to Postgres users. All the compute options we've launched are options for you on Azure and they're also built into many of the products and services that you use day in and day out. If you're using Teams at work, it's likely AMD is powering some of your session. If you're a Microsoft founder user, inference is likely being served by an underlying Epic or Instinct architecture underneath. A lot of the agentic AI workloads these days are running on C fuses well, so Epic is definitely a part of that. The biggest AI analytics and database services are all using AMD today to handle your workloads. Some giving you a choice and some taking care of it all of it for you. The the nearest and dearest, of course, to us in this talk is Azure DB for Postgres SQL, which gives you a choice in flexible server and provides AMD in the back end for upcoming products like Horizon DB. So, when you do have the choice, how do you know if your computer or your VM is powered by AMD Epic or how do you even find it? Well, look for the lowercase A in the name. The vast majority of VMs you'll see on this page have that A I'm highlighting here, from the BASv2 to the NV ADSv5710d5. That's a that's a mouthful. There are a few exceptions like that LSv2 I talked about that's actually going to be retiring soon. And the H-series VMs, which have been AMD only since HBv2 was announced back in 2019. Azure has been very consistent in the naming structure outside of this one exception for many years now. So, just basically look for that letter A and you're on the right track. Now, I want to show you the alphabet soup that I live and breathe every day so you don't have to. I won't read through all this, but take a look at the number of VM families that you can choose from and you'll see that it covers just about every workload you might need without having to procure and manage your own hardware and data centers. That's the beauty of the cloud and the beauty of Azure and the choices you can make. So, what's interesting though is that the pass and the SaaS providers like Azure DB for Postgres and Horizon DB also are are from this menu of options. For Postgres, we'll focus on the most common VM types, which are going to be the general purpose DA families, the memory optimized EA families, and the compute optimized FA families. And we're going to focus primarily on the latest generation V7 that went live earlier in 2026. Before we dive into the details of those specific VMs, it's worth noting the the sheer scale of what Azure offers in terms of regions and compute diversity. I regularly count the number of Azure regions available and where you can find AMD computer or not. And as of my last check, which is probably out of date by this point, cuz everything's changing all the time, you'll find AMD options in each of the 65 Azure-controlled public regions. So, Postgres users will definitely focus on the most widespread, general purpose, memory optimized, and compute optimized options. So, if you have a favorite region and you don't see what you need, then definitely reach out to your Azure contacts or to to my myself, and Andy will give you my contact info later on. So, let's get into the nitty-gritty. As a brief intro, the general purpose DA family, this is the V7, is best for many workloads as it's general purpose, and it comes with either 4 GB of memory per vCPU or virtual CPU, or 2 GB. Look for that little L in the name for lower memory. If your workload can handle lower memory, you're going to save 10-12% on average by moving to a lower memory skew. These VMs scale all the way from from 2 to 160 vCPUs, which I highlight because the prior generation topped out at 96. So, a lot more scalability in this generation. These D-series VMs also come with them without local temp disk. You look for that little D in the name to see if there's a temp disk. If you don't need that temp disk, then you can save 3-5% on average by not choosing that skew. Next are the memory optimized EA family, which increase the memory to 8 GB per vCPU. This comes with a 31% give or take cost increase. So, if your workload doesn't need that much memory, stick with the DA family for sure. Speaking with the PostgreSQL SQL product team at Azure, if you go to build or you go to ignite, you'll be able to talk to them directly. And I have the EA series are often most recommended because the extra memory gives you more room to scale, and PostgreSQL absolutely benefits from having more memory for per VCPU. These VMs, like the DA series, also scale from two to 160 VCPUs. Last but not least are the compute optimized FA family, which come with two, four, and eight gigabytes of memory per VCPU. In this case, you get a full core as a VCPU versus a thread. So, SMT would which is what Andy offers, simultaneous multithreading, is turned off here. So, you're going to see some of the highest performing uh highest performance in the F FA series without having to go to specialized computer options like the H series, and those are way less available around the world. These compute optimized families VMs, they scale from one down from two in the prior gen to give you a little bit more flexibility, up to 80, which is up from 64 in the previous generation. What's new as well is that they added temp disk on this generation. A lot of customers are asking for it, and so uh Azure listened and is offering that in the V7 version. These VMs do come with a price increase about 50% over their corresponding DA or EA series VMs. So, it's best to really use them for bursty workloads or where you pay per core for a software license. That's not really relevant to uh most people using Postgres. Um and you know, you don't have to think about it too much, but if you do find yourself CPU bound in your testing, so going from an EA, you would look at the FAM series, for example. If you're on DA, you look at the FA. DAL, you look at FAL. So, that's the guide for V7, and that's where I would really start to look first and foremost. So, going into how we enable all of this hardware and infrastructure on Azure, we're really investing heavily in open source technologies to run often on AMD processors and on Azure services. AMD itself is a top 10 contributor to Linux kernel development with a focus on day zero enablement for all of our hardware, CPUs, GPUs, and everything in between. And we serve it as a long-time long-standing member of the Linux Foundation. So, lots of projects and and future contributions there. How does that benefit Postgres itself in practice? Well, the improvements built into the Linux kernel, especially around IO movements and improvements, they flow through to Postgres. So, Phoronix did some really interesting testing of various database workloads using a fifth gen epic server, which is the same family as what you're going to find on those V7 VMs we talked about before. And they found that moving to that kernel V7.0 from this V6.19, the previous stable version at the time, improved throughput per second or TPS by around 20% and reduced latency by nearly 17%. That's for a mixed read and write scenario, so that's pretty common when you're using Postgres in a multi-user environment on the clouds. I really like the benchmarking they did there. If you recall the title of this talk, which is how choosing the right Azure infrastructure can improve Postgres performance by over 60%, this combination of software and hardware improvements over time is exactly how it's done. So, typically when I talk to customers, they're maybe, you know, they're stuck or not necessarily stuck, they just, "Hey, it's working. I'm on an older Postgres version, I'm on an older kernel version, older hardware. I don't need to change it up. It's just working." So, that's really common. Uh it's really tough to justify moving away from something something that just works, but let's talk about why it's almost certainly worth it from an economics perspective. So, AMD benchmarks each new generation of infrastructure released on Azure, measuring throughput via transactions per minute or TPM like you saw before in the Phoronix testing. The benchmarking we do might not fit exactly what you do, so obviously go test for yourself, but here's what we do basically. Or here's how we compare things. So, we go back a couple generations to a 5-year-old VM on Azure, which is an AMD-powered memory-optimized E16asv5. And that one comes with 16 cores, which we've been told, "Hey, a lot of customers are using 16 or eight, maybe 32 cores, but often the smaller smaller sizes." One modernization path you might consider is upgrading while maintaining the cores of the vCPUs. So, you move up one generation to an E16asv6, and this gives you a nice throughput per dollar benefit even at a slight increase in compute cost moving from V5 to V6. You'll see that the throughput per dollar uplift goes up 20%. The raw performance is up 26%, so that means there's a little bit 5 or 6% cost increase, but it's more than made up for by the performance. We also measure what's called a cloud opex, or operational expense, savings, which is basically a calculation for if you're going to do the same exact work given the performance and the cost, how much less or more would you pay? In this case, to do the same work as what you did on V5, you're going to save about 16% in operational expense. So, if we talk about V7 earlier, what if you can get your hands on a V7, in this case an E16asv7? This is where that the title of the talk comes from. So, you're going to get over 60% improvement and with this with this play. As you can see, even with the slightly higher cost of V7 over V5 again, that 63% performance improvement translates into 54% throughput per dollar advantage. So, ultimately for the same amount of work, you're going to save 35% in compute costs. So, if you can get the V7, absolutely go there. It's definitely the best bang for your buck. Another option you might want to consider is reducing the number of cores driving your database. Even reducing by 50% from 16 to eight cores, you're going to you're going to you're going to save quite a bit just because of the sheer reduction in compute cost by 50% typically. So, in this case you can go to an E8asv4 7. You're going to lose a little bit of throughput performance, so 9% but you're going to gain significantly the over 170% in throughput per dollar. If you can handle that slight drop in performance, you can still save 63% in operational expense costs to achieve the same amount of throughput as before. So, whether you're in your own data center, you know, looking at 5-year-old or or older servers, another cloud looking at older instances there, or already on Azure, modernizing to the latest AMD infrastructure is going to mean that you're going to get the same great PostgreSQL experience you're used to while improving the performance and the economics. Simply put, the modern AMD on Azure infrastructure is going to deliver more work per core for PostgreSQL. So, absolutely take a look and see if it's worth it for you. I've been speaking primarily here about deploying PostgreSQL on Azure in a self-hosted way, so we're picking the VMs and the specific one that you want. In this self-hosted infrastructure as a service model, you can tune everything from the PostgreSQL.com file to the actual database version, the OS specs, how you compile things, and more. The AMD teams that are working on benchmarking are typically testing in IAS, and so they're tuning to get the most performance possible in each generation based on the compute chosen. So, we do that often for customers, and we try to make sure we get the best out of every uh every new generation. As an example, we see customers when we do with our benchmarking, we typically set shared buffer parameter to 70 to 75% uh of memory. >> [clears throat] >> So, you can see just how much choice you have. I already talked about 60 plus compute options across Azure's as a last check, 65 public regions. The newest V7 VMs we discussed run 12 regions and growing. And this is might be way out of date by the time you watch this, but you know, it's constantly changing, but 12 regions. So, not nearly as much as what we have in V6, which is nearly everywhere in 58 regions last I checked. And the V6 confidential options, which I'll talk about in a minute, are in 17 regions. So, there's lots and lots of choice, which maybe you don't want to deal with. That's totally fair. In that case, you can of course choose to deploy Azure DB for PostgreSQL, the platform as a service option. You can still tune parameters available in the Azure interface, but you won't have access to every option in the config and the config files. That helps you reduce operational overhead, but of course there's some trade-off in that the service has fewer fewer options, fewer choices. That's to be expected though, and new options are continuously rolling out. So, this this may change of course throughout the year. In this platform as a service offering, you can choose from three different tiers, general purpose, memory optimized, and burstable. And AMD is available in the first two, general purpose and and memory optimized, with V5 in 15 regions, V6 in five regions, and confidential compute in three regions today. No V7 just yet or confidential compute V6. So, if you want that option, then IaaS is the way to go, but the choice is up to you, of course. So, speaking of confidential compute, Azure Database for PostgreSQL was one of, if not the first managed database service to offer this capability. AMD's built-in hardware security features, including secure encrypted virtualization or SEV, as we call it, you're likely used used to encrypting data at rest and in transit, but in use is relatively new, which is what confidential computing is all about. And Azure has been a real pioneer in this space. SEV protects data in use, which reduces your attack surface, and protects you even from people walking the data center where your compute lives. A lot of com- companies have that kind of threat model where they have to be I mean, not overly protected, but they have to really think about how they can protect their data no matter where it is, whether it's in their own data center or in someone else's. With this, no application changes are required. You simply pick a confidential VM SKU, like DCA or ECA. See that big C? It means confidential, basically. They're the same exact specs as the D A E A that we talked about before, but with confidential compute feature turned on. There's no cost increase, either, for this choice, and we'll get into the performance impact, but depending on your industry, enabling confidential compute may be the best way to deploy in the cloud because you need to have that extra trust to make that transition. We see quite a bit of interest from government, finance, and healthcare companies see confidential VMs rolling out in government regions for Azure and and the sovereignty play. And Microsoft themselves have been very public about deploying a large amount of confidential VMs for their secure futures initiative, for Windows licensing operations, etc. So, a lot of a lot of uptake there. While costs and application changes are not required to adopt the confidential VMs, there is a small performance impact to consider. Phoronix has you all done really great testing of the V6 confidential VMs, which you can use in IaaS today, and found a 3 to 6% overhead on average. Database workloads are impacted a bit more than others, given the significant data movement involved, but that performance hit will still put you well ahead of the performance of prior generations of non-confidential options. What's most interesting, to I think to me, is that there's no tuning required. So, you just select a confidential VM, and you'll have you'll have that small performance impact, but it will just work. No tuning required. AMD's working hard, generation over generation, to to reduce the gap here, and you should see more and more progress in this area soon, and hopefully some more options available uh and on Azure. Phoronix also did check performance against two Ubuntu versions, and found no significant changes. So, again, a lot of work is happening in the background on open source enabling to at least stabilize or improve performance of hardware features gen over gen. Speaking of enabling, PostgreSQL has really led the way in creating AI-ready features that you can so you can do more with your favorite database. It really is kind of becoming a one-stop shop for all sorts of data data management uh not just standard but going into the AI space. So, three areas come to mind here. PG Vector, Disk ANN, and AVX-512 enabling, which all benefit from the combination of software and hardware enabling that's now here with the fifth gen epic infrastructure on Azure. PG Vector itself has been around for a long time. I think over 5 years at this point and it brings native vector similarity search to Postgres. Microsoft Research actually has done a ton of work in developing and releasing Disk ANN or Disk Approximate Nearest Neighbor, which enables vector indexing on fast storage to scale beyond memory. So, maybe you want a D-series and you want to enable vector processing, you can get the local temp disk or or fast remote storage and enable Disk ANN in PostgreSQL in the the pass or the IS version. The blog post that announced the GA in PostgreSQL for Disk ANN claimed up to 10x faster speed, 4x lower costs, and up to 96x lower memory footprint than the industry standard PG Vector HNSW. This is a really huge deal when memory costs are skyrocketing and fast NVMe SSDs are lower cost and now pretty much ubiquitous across Azure and data centers generally. And I'll hopefully you're using one in your local your local PC or or work laptop. V6 and V7 VMs come standard with NVMe remote storage and you can also deploy local NVMe temp disks that we talked about. There's also some storage optimized VMs, the L-series, that would be a really great fit for Disk ANN if you're doing massive amounts of of of vector processing. You can use this again as on pass or deploy as an extension on IS. I think it's a bit more easy on the platform as a service Azure DB for Postgres, but it is possible to roll your own as well. Enter AVX-512 or Advanced Vector Extensions with 512-bit data path. This is what's known as SIMD or Single Instruction Multiple Data. A single CPU instruction can process, in this case, 16 32-bit floating-point numbers simultaneously or 512-bit in total. PostgreSQL first supported this in Postgres 17, and then there were significant enhancements made in Postgres 18, which enabled 3x faster checksums. And this helps improve write-ahead log integrity checks and database backup speeds, for example. So, a lot of great work has been put into this. PG Vector itself can can use AVX-512 for various similarity search algorithms, directly accelerating those operations. What's great about PostgreSQL 18 in is that at the in the runtime, if your hardware supports AVX-512, the software checks and should take advantage if available. The V7 VMs on Azure have this capability, as do the V6, albeit they use a slightly less efficient, what's called double-pumped 256-bit implementation. Still get the 512, but not as fast as the V7. Once again, Phoronix did some really great testing of the fifth-gen EPYC with and without AVX-512 enabled across a wider range of workloads. They found on average 45% improvement over the non-AVX enabled fifth-gen, and 12% more throughput over that 256-bit implementation I mentioned on the prior gen, fourth-gen EPYC. What's even better is that these modern implementations, yeah, get you get this extra performance without a significant increase in power usage, or may maybe even the negligible increase if you look at the Phoronix data there. Then you don't have to worry too much about power in the cloud necessarily. It comes across in your bill ultimately. That's why you'll notice a lot of the AMD options are typically lower lower cost than the non-AMD options. But if you care about your performance per dollar per watt, the Azure AMD V7 VMs will improve all those vector operations, CRC checks, and JSON parses you're doing day in and day out. So, you've covered a lot of ground in a short amount of time. There are going to There'll many great talks at Postgres this year, and I know you'll learn a lot outside of this talk. I covered a lot, so if you want to dig any deeper, I've got lots of resources here for you with these QR codes. Take a look at one that detailed tuning database guide we've published. Some of my uh really expert colleagues have put that out. They're part of the ecosystem enabling team here at AMD, so we're constantly putting out guides for your favorite workloads. We also co-wrote a migration guide to post to Azure Postgres whether IaaS or PaaS with all the nitty-gritty on how to move to the great Azure options we heard about today. You can also look at a general AMD tuning guide for just Azure VMs overall. It's not necessarily Postgres focused, but just shows you all the options and how to get the most out of your IaaS uh choices. If you're more interested in uh confidential computing topics, and believe me, it's a fascinating area. I think it'll become more and more needed as uh and I hope more and more providers use, especially since I as a privacy nerd will benefit absolutely. Take a look at that ebook in the center about confidential computing. Uh my colleague Noor, who works in optimizing workloads for customers day in and day out, and it's a lot of what AMD teams do, she wrote a really nice guide on how to make sure you're using AVX-512 or it's enabled in your workloads, so absolutely check out her blog post. She did some really detailed work there. I think you'd uh you'd enjoy. And for more info on all the Azure and AMD products and services, including customer stories and trial offers, you can check out that newly updated partnership page on the bottom right there. Last but not least, you can always reach out directly by my LinkedIn. I'm on Discord, uh and you can reach out to the Azure team uh at amd.which I'm a part of, azure@amd.com. We'll be able to respond to you by that email address. >> [snorts] >> So, uh that's it for me. Thanks for joining Posette 2026 and for taking the time to watch this talk. Enjoy the rest of the show.