Azure Database for PostgreSQL Reviews

Our main use cases for Azure Database for PostgreSQL include security dates, security tools, and a couple of small applications that move data and read data from other sources such as logs or claims and process it. Some of our use cases are simple websites that use Azure Database for PostgreSQL.

We are starting with Copilot and agents built from Copilot. It will almost be the year of our agent for next year because many people are asking for Copilot Studio. On the keynote, we saw the old App Maker or App Builder. I am always looking at how people can make small things and be out the door already using the Azure Copilot environment. We are looking forward to that.

we are working to a proof of concept. so we are totally ready to see what can be improved.

The most valuable features of Azure Database for PostgreSQL for us are reliability, performance, and cost, making it a good cost-benefit for us.

For Azure cost-benefit, not having an on-premises solution and having Azure Database for PostgreSQL on Azure means we leverage Azure Database for PostgreSQL being built and maintained by Microsoft engineers who know far more than I do. They already have the experience to ensure that the application is up and running and any recommendations that come from it. For example, they provide recommendations such as 'you should probably run it like this' or 'you are missing some optimizations.' That is the kind of information I would like to see.

Patching is seamless. The applications we have running there, SharePoint, and all the other services, those get patched and we never get any downtime. Having databases up and running all the time would be great because it is a struggle now.

We would love to definitely see scalability. We would love to see it grow as more people use it and it can handle the data and maybe tell us some optimizations by reporting on what we have. Hopefully, we will see more security features. We can ensure that we are doing good governance on that and that the data that should be there is there and we are controlling access to it.

I have been in my current role for about five years.

Azure Database for PostgreSQL is very stable. Many companies have blips when their internet goes down and things happen. All cloud platforms experience downtime, but it has been very available for us.

It is something we can spin up and test and start running for applications on a small level. Once you can prove that, we can go big. We do not have to buy everything and build it. It is already there. We just throw on a switch, and it is ready to go. We can use that much. Later on when people say they like it, we can say great and really ramp up using it.

We have not expanded usage at this time.

I have used Microsoft Support, but not for Azure Database for PostgreSQL. I have used it for other services.

I would rate it an eight because sometimes I get someone who knows their material and they solve the problem quickly. Sometimes I have to jump through hoops of doing many things and then the person says they cannot solve it. That is when I realize they are just reading from a script. When I am in a time crunch, you want to get to an engineer level problem quickly. Sometimes it takes too long for me to get to an engineer level problem that I want, but sometimes I get there and find a person who has the solution. I think that is great.

Positive

We looked at Snowflake. We were looking at other options. We have a little bit of MySQL, but that is not really cutting it anymore. There is Azure Database for PostgreSQL running on another cloud vendor as well.

The setup is fairly point-and-click. We just look at the steps to grow it. All the other decisions on the other side are on Microsoft's side. When we want something this big, Microsoft makes it happen. I do not have to think about how much memory I need or how much RAM I need. I do not have to think about whether the server is going to be big enough or what we have to build or whether we have to build a cluster now. We do not have to do that anymore.

At this point, that is not applicable. Someone else sets it up. My manager and the vendors set that all up.

For us, the build was fine. It is mainly repointing information. We are kind of interconnected, so you have to find a database that is not something we move and that is pretty standalone. It is mainly figuring out what our own business is and what is pointing at it more than anything else. Once you figure that out, you can change the connectors and everything else. That is more from the application side and our UC4 and any automatic processes that we have running or SQL processes.

I would say the ROI is a nine because we are just starting to want to get it up there and it has been easy for us to build up and do a small thing. We have not stressed it out yet. We are trying to get to the proof where we are talking to one group and saying let us move something else over there now. That takes time. We are not quite there yet where we are really stressing something out.

advise to get E5 for better security and governance of your data and systems

I do use Azure Active Directory integration for security. Using Azure helps us say you only get a certain amount of access based on whether you are a corporate device or your own device. We are already using features like that to help secure and keep our data safe.

We are starting with Copilot and agents built from Copilot. It will almost be the year of our agent for next year because many people are asking for Copilot Studio. On the keynote, we saw the old App Maker or App Builder. I am always looking at how people can make small things and be out the door already using the Azure Copilot environment. We are looking forward to that.

I do not think we are there yet to really get that benefit. I do not think I am there yet either. Our overall review rating for Azure Database for PostgreSQL is nine.

Hybrid Cloud

Microsoft Azure

My main use cases for Azure Database for PostgreSQL are Edge, Edge AI, and edge data consolidation.

What I appreciate most about Azure Database for PostgreSQL is not one particular feature; I think it is the use case and the facility to have a single pane of glass for managing what is on the edge, what is on the cloud, especially now with Azure Local as well. It is not a product per se; it is the ecosystem integration overall.

The ecosystem integration of Azure Database for PostgreSQL benefits my company by having fewer moving parts, fewer points to break and touch. It simplifies operations and provides a seamless interface.

Microsoft needs to start developing specific agents that would be focused on Azure Database for PostgreSQL. It is almost like in the database world where stored procedures exist. Creating similar stored procedures but for agents within the database would be beneficial. This is not easy to implement as it requires architectural changes, but this would be a game changer for everybody.

I have been using Azure Database for PostgreSQL for approximately ten years.

I would not know if my company's database uptime has changed after implementing Azure Database for PostgreSQL because I am not tracking that. A team tracks that, and I have not heard any complaints, which I think is a good sign.

My impressions regarding the latency and availability of Azure Database for PostgreSQL are positive. Overall latency, especially for edge deployment, needs to be very short and very low, and that is what we are getting.

My impressions of Azure Database for PostgreSQL's ability to scale workloads are within what I expected. However, it is scalable up to a certain size and volume. Some of the use cases that I have on edge are simply not possible to do with PostgreSQL given performance requirements, which is why we are exploring other options with Microsoft.

I would rate customer service and technical support at Microsoft an eight out of ten. They have good technical support with no complaints.

Positive

Regarding my experience with the migration process to Azure Database for PostgreSQL, we did not use Microsoft support. We had the skill set in-house, so the migration was relatively simple to execute. We performed it at an application data layer rather than at a DBA level.

Azure Database for PostgreSQL has not helped reduce infrastructure costs.

The pay-as-you-go pricing model of Azure Database for PostgreSQL has actually increased costs. The licensing model that I had before in some use cases was very beneficial and included volume discounts. Once you move to that model, if you do not have it tightly integrated with FinOps, you will pay more.

In comparison to my previous expenses for maintaining an on-premises PostgreSQL database, the costs are higher.

Azure Database for PostgreSQL has not influenced my application development process.

Azure Database for PostgreSQL has not moved the needle in terms of my ability to innovate or stay competitive in my industry.

The integration of Azure Database for PostgreSQL with other Azure services has not impacted my overall cloud strategy.

We continue to share with different clients a positive view of Azure Database for PostgreSQL, and there are use cases for it, but it is not universal. There are other options available. We do have several pilots going on, especially for edge deployment. I would rate this review a nine out of ten.

Public Cloud

Microsoft Azure

My main use cases for Azure Database for PostgreSQL came from a personal project to scratch an itch, and it was the easiest one to go grab.

I appreciate how easy PostgreSQL is to get running locally. You can grab a container and run it, as opposed to the old days when having a local database was very challenging and required special scripts that would take hours to run. Now I can grab a container and be good to go in seconds, which makes life a lot simpler and has influenced my application development process.

My experience with the monitoring and management tools provided by Azure Database for PostgreSQL has been minimal, but the ability to see what's there and tweak it is a good feature to have.

Azure Database for PostgreSQL security features such as encryption and advanced threat protection are very helpful, especially when you have medical data and personally identifiable information that you need to protect. The fact that these security features are embedded certainly makes my job easier. The ability to encrypt personally identifiable information and health data at rest is what my company finds most valuable.

Azure Database for PostgreSQL integration with other Azure services has impacted my overall cloud strategy. Depending on the customer, having it there and having it be easy to utilize, with the ability to switch to it, is valuable. I have conversations where customers are using one data store, but maybe that's not the right data store and perhaps another should be used instead. The fact that you can do this with such a low barrier of entry makes it simpler to have those conversations. It isn't a situation where you have to hire somebody who knows how to stand this up; you just click and now you have that data store.

Azure Database for PostgreSQL integrations have been most beneficial to my operations with Azure Kubernetes Service and Container Apps. The different eventing systems provide another valuable conversation point about which of the three different eventing systems should be used. The different tiers available allow you to think in terms of crawl, walk, run. You don't have to go straight to the heaviest duty enterprise level until you need it. When you're just getting started and trying to find market fit, you can use something simpler that gets you up and running with some training wheels and fewer knobs you need to worry about. When demand requires it, you can graduate to the next tier up.

Azure Database for PostgreSQL has helped reduce infrastructure costs depending on the client.

Azure Database for PostgreSQL can be improved in ways I'm very curious to explore with Horizon. I'm interested in seeing how the fully enterprise-hardened features change things and where that blurs the lines with other data stores available on Azure, as that will probably make it harder to choose between solutions.

I've been working in my area of expertise for almost thirty years.

Compared to my previous expenses for maintaining an on-premise PostgreSQL database, Azure Database for PostgreSQL is far easier, far simpler, and far cheaper in my opinion. Having to maintain staff whose job is the care and feeding of the database and the time it takes to get a local version spun up for somebody was a burden. Being able to do that with some clicks is a huge win. Additionally, you don't have to worry about whether it's up to date, because it always is.

I have previously used an on-premise database.

Azure Database for PostgreSQL has influenced the adoption of artificial intelligence technologies in my company. Artificial intelligence is definitely in almost every conversation that happens these days. The clients I've worked with haven't used it yet, but it's at least in the air. That's another thing that will eventually have to tie in, depending on the customer.

Azure Database for PostgreSQL has had a significant impact on my company's data protection strategy compared to previous solutions. Not having to manage it yourself is a huge win. You can shift that responsibility to someone else who does it at scale and can hire the best people in the world to do it. It's one less thing that you need to spend cycles on, so it's just an overall win.

My experience with the migration process to Azure Database for PostgreSQL, particularly in terms of the technical expertise required and support received from Microsoft, is generally straightforward as I've seen it. It helps to have people who've done it before and know the pitfalls and can help you speed things up, but by and large, it's a fairly straightforward proposition. How much data you have does matter for the timeline.

I would rate Azure Database for PostgreSQL overall a nine out of ten, and we will see how the Horizon offering works.

My advice to other companies considering Azure Database for PostgreSQL is to choose the data store that makes sense for your use case. I've noticed a tendency to just grab whatever database was used last time, but maybe that's the right choice and maybe it's not. I've seen instances where people choose a data store because they think it's cool or they want to play with it and put it on their resume. Resume-driven design is a real thing. Make sure the data store you choose is the right one for your use case. If you're doing microservices, you don't have to have one-size-fits-all. If a service needs a time series database, then use that. If a service would benefit from graphs, then use graphs. Use the data store that fits your needs.

Public Cloud

Microsoft Azure

My main use cases for Azure Database for PostgreSQL are to use it as data storage for a lot of apps, involving different app services, functions, and other platforms, where we bring in and process a lot of data for integrating different cloud platforms. We have document management systems where we're pulling back-end data from on-premises systems or other cloud systems, using many Azure functions and different app services to pull data through Azure Database for PostgreSQL to track and sync with other systems.

Azure Database for PostgreSQL has influenced my application development process by enabling me to take some of what we used to do on-premises, with PostgreSQL hosted in virtual machines, and transition that process into a SaaS solution. This transition means we don't have to spin up a virtual machine for installation and configuration, streamlining the process and making it faster and allowing us to script much of it out, so whenever our developers need a new environment, it's just a couple of clicks and an automation, resulting in a consistent build every time.

The impact of moving to Azure has been significant; we can take what was already built on-premises and split it into services without needing to build a whole server, making the deployment much lighter, faster, and scalable.

My favorite feature about Azure Database for PostgreSQL is that it's quick and easy to set up and deploy, without a lot of overhead or configurations, making it fast and easy to include in any of our builds. When we automate for scaling up or scaling out, it's easy to do that automation side of it, and since it's PostgreSQL, it's lightweight and simple for the basic things we need to do from a data perspective, so it works well.

A benefit that Azure Database for PostgreSQL has for my company is that it serves as a native back-end solution for several utilities and tools that we use, making it a quick and easy solution that we deploy as part of larger problems or solutions. This capability helps us scale economically because we're often reselling these solutions, keeping our costs down and making deployment and rollout easier.

My impression of the security features in Azure Database for PostgreSQL, such as encryption and Advanced Threat Protection, is that it has met all of our security requirements; anytime our apps go through a security review, we've never had any issues while using identities and registering the app. It has been great, trusted, and it works without needing extra security reviews for implementation.

Regarding improvement in Azure Database for PostgreSQL, I would have to discuss that specifically with our lead developers.

I have been using Azure Database for PostgreSQL for approximately seven or eight years.

I can assess the stability and reliability of Azure Database for PostgreSQL as excellent; we have no issues or problems with it. Occasionally, we experience throughput issues due to bandwidth limitations of client setups with Azure, which have limited connections, but as far as the service itself goes, it has been rock solid.

In some ways, Azure Database for PostgreSQL has facilitated adopting AI technologies in my organization, mainly because we can take output from AI processes, particularly document and contract summarization, and dump that data into a database for later retrieval. We are only beginning to experiment with this and hope for more native solutions within the AI tools, which are now coming, and PostgreSQL has allowed us to lay the groundwork for this. I rate this product a 10.

Public Cloud

Microsoft Azure

We are an insurance company with many applications that handle policy processing, so we use Azure Database for PostgreSQL for those applications. We have different usage for every database, and for all of our in-house applications, we use Azure Database for PostgreSQL.

We have monitoring for Azure Database for PostgreSQL. Our on-premises monitoring is connected to LogicMonitor, which we use as a centralized monitoring tool. If a database has any task that has been interrupted or any connection issue, it will alert LogicMonitor, and we have a centralized panel for all the alerts.

Regarding Azure Database for PostgreSQL security, I have not received any report or incident indicating a breach to our database. However, I cannot definitively say this is because of Azure Database for PostgreSQL or our overall security ecosystem.

I am not certain if Azure Database for PostgreSQL helped reduce infrastructure costs because we are in the process of migrating to the cloud. Our on-premises cost and on-premises infrastructure cost is fixed, and we pay an annual fee to the data center. Once we migrate to Azure, I could check the cost bill, but I have not yet. This is not my main responsibility. The management definitely did an estimate, and I think it will probably save some money for them, which is why they chose to migrate. That is my assumption.

I am not a DBA, so for my experience with Azure Database for PostgreSQL on the database side, I do not know if it has certain capabilities. The most significant thing I do and communicate with our DBA about is performance tweaking. I think we still have to do it regardless because you still build on a server with the OS level on it. I do not know if in the future the database will have its native OS layer instead of using Microsoft and dynamically assign the CPUs and memories based on the transaction or task it is running. This could save us some time so it does not have to use sysadmin's time to constantly tweak and assign the CPU. Currently, most databases will try to use all the CPUs available and use all the memories available. We try to give all the databases one hundred percent of the hardware capacity, but sometimes because the OS layer itself will need some resources. If the database used everything, when we try to remote to it, sometimes you will just see a black screen. If we can make this better, why not?

On the deployment side of Azure Database for PostgreSQL, it is easy to deploy. The deployment of Azure Database for PostgreSQL is pretty straightforward, and there is not much to specify. It is very basic. Usually I will work with the DB team, they will give us all the instance, all the SSA, and all the accounts. We basically deploy, install it, and deploy it.

The deployment of Azure Database for PostgreSQL usually takes one hour for us to deploy it. I do not know if the deployment time for Azure Database for PostgreSQL is similar to other solutions. For MS SQL, I think it is also the same amount of time. For AWS, I cannot say because it is a cloud team thing, and I deploy on-premises.

I am the admin part, so I basically deploy Azure Database for PostgreSQL. I do not actually directly use the product, but I do the deployment.

I cannot say much about the features of Azure Database for PostgreSQL because I am not the actual user and just do the deployment.

Azure Database for PostgreSQL has influenced our application development process, which is the reason why we stick with Azure Database for PostgreSQL. Otherwise, we would not use it as heavily. Our company's strategy is always to not put all eggs in one basket. We have Azure Database for PostgreSQL, MS SQL as well, and some AWS databases. We have all kinds of DB and also MongoDB.

For our solution using Azure Database for PostgreSQL, I have never gotten any complaints from any incidents, security incidents, or any technical troubles. It is very rare, but incidents are code-based and not database-related. We have some code-based incidents because the application has some bugs, so we have to fix them. Based on the database itself, the most tweaking we did was the performance. We have to monitor the performance of all the transactions and all the journals, and we have to do tweaking such as determining how many CPUs and memory we have to reassign to those servers and applications. That is the only thing that we actually deal with. The patches happen on the Windows server side because we use Microsoft servers. Most of the patches happen on the Windows server side, though we have Linux servers too. When Microsoft releases some patches, it will sometimes interrupt some connections, but it is not a PostgreSQL issue and is just a server issue.

We are a hybrid environment including our on-premises AD. We are in the process to migrate and try to get rid of our on-premises AD and completely use Entra as our main identity management solutions. Currently, we are hybrid and everything is Microsoft. We also use Okta as well. We have Okta and Entra. The hybrid arrangement has its advantage because it really connects our old legacy technology. Everything has to be on-premises because we have not had time to completely convert it to cloud apps yet. The hybrid approach creates a bridge to both worlds. A native cloud approach actually has more advantage because it is easy to deploy, faster to deploy, and easy to recover and roll back. It is more agile and more convenient for us. It really shortens the time for us to deploy on-premises. When you try to deploy something on-premises, especially when a new product comes in, you have to get the hardware, set up all the firewall rules on-premises, and then deploy all the applications on those servers. Because we moved to AWS and moved to Azure, everything is basically just policies, and you can define everything in the cloud. It is way faster and more convenient for us. I gave Azure Database for PostgreSQL a rating of nine.

Hybrid Cloud

Microsoft Azure

We started using Azure Database for PostgreSQL about five to six years ago. Initially, we were doing an on-premises Kubernetes setup, but since Azure was accepted at the bank, we moved to Azure. We currently run fairly large clusters with around five clusters spanning three environments, along with disaster recovery aspects and smaller clusters for specific products.

Having a relational database like PostgreSQL, which is cheaper than competitors, is beneficial. We have extensive experience with SQL Server and Sybase SQL Server, but the applications mainly care about the backend database's total cost. As long as it meets the needs, it serves its purpose well.

While the flexibility of the server for financial reasons is understandable, better switching between primary and backup would make transitions smoother. I noticed an issue where the primary refuses to launch if the backup isn't running. Another improvement could be the ability to scale storage back down after scaling up, as we can do with compute resources. It's likely a financial restriction from Microsoft.

We started using Azure Database for PostgreSQL about five to six years ago.

When not abused and sized correctly, performance has been very good. We are holding large volumes of data, and it has been doing well for us.

We can scale up compute and scale it down, but once storage is allocated, there is no way to scale it back down.

Given the amount of money we spend with Microsoft, we receive excellent support. As a big bank, we get prompt responses, especially for high-severity issues. Once we open a support case, we have people engaged within about 20 minutes, especially for a Sev 1 issue.

Neutral

I have a lot of experience with SQL Server from a previous position and even more with Sybase SQL Server from a previous role.

We abstracted the normal Azure creation mechanisms using a PowerShell-based system. I create a JSON config with the server details, and it quickly creates them. Initially, running the templates required frequent updates as configurations drifted in a young system. Now, it's managed behind the scenes, and I don't experience the pain.

It doesn't take much to maintain. We have a couple of individuals managing it alongside their other responsibilities. It operates like an internal open source project, where anyone can contribute. If an issue arises, I communicate it to them, and they address it.

Overall, Azure Database for PostgreSQL has been good for us. When sized properly, performance has been great, and we handle substantial data volumes. I would rate it an eight or nine.

Hybrid Cloud

Microsoft Azure

We have a few custom-built applications where we use Azure Database for PostgreSQL as the database layer. It is not used for Azure Database for PostgreSQL because it's for an online service.

Horizontal scaling has helped manage our workloads, making it easier for us to stay cost-efficient while also scaling when we get more traffic on our application. Our applications often don't get as much traffic, so we can scale down in terms of cost efficiency by utilizing Azure Database for PostgreSQL. If there is a reason why the traffic goes up, it scales up without our hands on the service.

Azure Database for PostgreSQL is fully managed, so I don't have to manage it on my own. That's the main thing from my point of view.

When it comes to network integration, we always try to have everything in a private network. There were different options on how you can deploy it, and it was a bit difficult to understand what the right option was for us.

It's not so easy to replicate it to another region or something of that nature. At least, the last time I had my hands on it was one or two years ago, so perhaps things have changed.

I have been using Azure Database for PostgreSQL for three or four years.

We have not had any outages that I'm aware of with Azure Database for PostgreSQL, so it's working well.

Azure Database for PostgreSQL is not our main database, so it's working well for the purpose of scaling with the growing needs of our company.

Microsoft support for Azure Database for PostgreSQL rates about four out of ten based on my experience. You always get the same questions with Microsoft support, and it's not really straightforward. We already pay for better support. It was worse before, but now it's still worse, not as bad as before. It really depends on which team or which person takes over the case. We have a few good experiences, but the majority is not so good.

Neutral

For the service I had in mind, I did not use another database prior to adopting Azure Database for PostgreSQL. This custom-developed application was developed by an external company for us, and the technology and database were already chosen.

The experience with pricing, setup costs, and licensing of Azure Database for PostgreSQL was straightforward from my point of view. There is some marketplace licensing involved.

I have been involved in deploying and implementing Azure Database for PostgreSQL. We deployed the whole project through Terraform, and it worked for Azure Database for PostgreSQL with no issues.

To be honest, I don't know how much money we're saving by horizontally scaling up and down in terms of return on investment in Azure Database for PostgreSQL. I think it's mainly operational cost that we save.

I personally did not consider any other database for this project.

That's something I would need to ask our developers regarding how Azure's integration with other services has impacted our application development. I have not realized other benefits from using Azure Database for PostgreSQL. This review received a rating of 8 out of 10.

Private Cloud

Microsoft Azure

We are building enterprise solutions mainly across healthcare but also in other industries like retail and financial services.

PostgresSQL is acknowledged as an incredibly powerful industry leader. We've built critical pieces of national infrastructure in the UK that rely on Postgres. A version of Postgres on Azure that's easy to adopt enables us to innovate. The addition of AI extensions is even more exciting. It's a significant opportunity for us.

While we haven't implemented any AI features yet, we believe that will help our development because of the platform's simplicity. The ability to write code and deploy applications using standard Azure principles will be a game changer, simplifying integration and deployment. 

Azure Database is simple and easy to use. We followed the prescribed training and upskilled 10 engineers. They think it's straightforward. They've already got PostgreSQL skills to optimize the solution, so they know what to do. It was easy to get started quickly and become effective.

My team speaks highly of the platform's observability and monitoring features. It's as efficient as an enterprise needs it to be and. has all of the tooling and telemetry necessary to run an enterprise database.

We take security seriously. The team has looked at the security features, and nothing has been flagged to us. My takeaway as a CTO is that they're comfortable with the security posture, the features, the observability, alerts, and now it integrates into the rest of the Azure landscape.

The OpenAI integration and extensions have massively simplified integrating AI into a database. PostgreSQL's native vector capabilities are also incredibly powerful. 

The critical service is the Azure OpenAI service. It would help to make it simpler and easier to integrate with that or cognitive services.

I have been using Azure Database for PostgreSQL for probably three months.

We don't have a solution in production, but there have been no complaints about latency or performance. However, we haven't got any stats to back that up or anything hard. It's all anecdotal based on the opinions of 10 hardcore developers, including experienced database engineers. 

So far, we have encountered no scalability concerns. However, we can see how well it scales after we deploy it for some large enterprise customers or big government organizations. No one is suggesting that we can't scale to, you know, this to run big critical national infrastructure projects.

The experience with support has been fantastic. The documentation and training we've received through Microsoft Learn on how to migrate, deploy, and manage the solution is exceptional. 

Positive

We have used PostgreSQL extensively on-premise and have migrated it to the cloud, expecting enhanced security and control in Azure compared to on-premise solutions.

The initial setup was seamless, and the quality of the training was commendable. 

We have used products like Redis Cache, which is powerful but expensive. Now, we use embedded PostgreSQL vectors, which will undoubtedly reduce the TCO by using a much more cost-effective solution.

The pay-as-you-go pricing model plays a critical role in managing database-related costs and resource allocation. We build using Infrastructure as Code (IAC) and maintain a focus on FinOps to control Azure service costs. Some clients are pushy on price. It's critical to automate it, so we're just using it when appropriate and switching it off in certain scenarios.

Previously, we used products like Redis Cache, which is powerful but costly. Now, Azure Database for PostgreSQL's vector embeddings mean we prefer it over Redis Cache.

I rate Azure Database for PostgreSQL 10 out of 10. 

Public Cloud

Microsoft Azure