Google AlloyDB Omni and Silk for the Win

In my Part I blog, I created a baseline and did a couple performance improvement tests with Google’s AlloyDB Omni, on Azure demonstrating the performance benefits of having Silk as the storage layer.  Silk offered the ability to run 23 times faster than native Azure premium SSD in the HammerDB tests and then some minor optimization of the database layer offered another 35% improvement.   

We’re not the first, nor shall we be the last to use HammerDB to perform benchmark tests against flavors of Postgres, but based off the published tests from Gigacom, how do our tests compare with Google’s AlloyDB Omni on Azure using Silk? 

Using the HammerDB test results, along with our own, we quickly see the huge benefit of using Google’s AlloyDB Omni with Silk vs. other Postgres flavors without: 

Now we are aware of the performance and scalability gains vs. single node deployments without Silk, but what would each solution roughly cost per month, (I calculated these on my own, so hopefully I did each of them justice around licensing/services and infrastructure costs)?

This graph can look overwhelming, but keep in mind, you need to balance it out with the performance and scaling you get for the price.  Outside of additional features or support, the next graph uses the monthly value per NoPM, demonstrating the real value:

Overall, these tests demonstrate wins for Google’s AlloyDB Omni when built on scaling infrastructure with Silk on any cloud or as a PaaS solution in Google, but I can’t help but think CockroachDB and Yugabyte could benefit from Silk, too?