Azure Database for PostgreSQL Reviews

Azure Database for PostgreSQL serves several use cases for me. I use it primarily for testing and development environments where I need flexible database access without long-term commitments.

The pay-as-you-go pricing model is one feature I truly appreciate. I can pay for only the amount of time I need the database, which is very efficient for my test environment and development work. I don't have to purchase upfront to gain access; instead, I just get billed for the specific hours I use the database. This makes me more inclined to develop when I know what I'm expecting. However, when I start planning for production where the service will be up for two or three years, I prefer to pay upfront, as the pay-as-you-go model becomes expensive for production use.

Another significant benefit is that I don't have to worry about power management and security concerns associated with physical servers. With a physical server, many people could potentially gain access, which makes tracking difficult. Azure Database for PostgreSQL allows me to create different user accounts with specific access levels, which greatly helps my monitoring process, logging, and incident response. I can monitor when my database is accessed by unauthorized users and receive alerts for those events.

Apart from the scaling aspect, I would like to see improvements in the user interface. If a guided journey could be created, I would prefer that approach. Some cloud platforms I've used have journeys that guide you through processes, but with Azure Database for PostgreSQL, I have to know exactly what I want to do and navigate there myself. This was not beginner-friendly for me at the beginning.

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

Regarding availability and latency, I learned that placing all my services in one networking environment reduces latency significantly. I put them in different availability zones to ensure reduced latency of communication between virtual machines and all my services alongside the database. Once everything is in the same networking environment, the latency becomes much smaller compared to when I have everything spread across different availability zones and regions, which results in higher latency.

Azure Database for PostgreSQL demonstrates strong scalability capabilities for my workloads.

Microsoft technical support replies very quickly. I have had two issues, and when I raised support tickets, I received responses within two to three hours and they were able to resolve both issues. My first issue concerned my billing account where my credit card was not being accepted. I reached out to support about a credit card that had been working previously, and they resolved it for me. My second issue was concerning session hijacking. I was trying to figure out the best approach to protect my company against session hijacking, where people's session tokens get stolen and reused by attackers. Support advised me to use the feature of making sessions expire after 24 hours, which means users have to log in again after that period. This was accomplished using Entra ID. If a session gets hijacked, attackers would be logged off after 24 hours. The support team was very helpful in resolving this.

Before Azure Database for PostgreSQL, I used on-premises solutions. When I was working as an intern, most of our servers were Microsoft servers housed in-house. In terms of power consumption and power accessibility, the shift to Azure has been beneficial. Having to power the Microsoft servers we had at that time was quite burdensome on the organization I worked with then. We had to use inverters and other backup solutions because we were in Nigeria where power issues are common. Everything related to power was expensive, but with Azure Database for PostgreSQL, we were able to run operations easily because all of those infrastructure costs were offset.

I rate Azure Database for PostgreSQL a nine out of ten.

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 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

As a Cloud Service Provider, I manage a significant portion of Azure Database for PostgreSQL deployments on behalf of my clients. I handle provisioning and configuring monitoring for these instances, so my experience is primarily from the platform aspect rather than the data level. I can share insights regarding monitoring, relevance, and metrics.

For the clients I manage, there is seamless integration between Azure App Services and Azure Database for PostgreSQL, which provides me with valuable experience in this area.

I appreciate the rich metrics provided by Azure Database for PostgreSQL, especially the availability metrics that enable me to receive notifications and manage expectations if anything goes down. This ties directly into disaster recovery solutions, allowing for faster failover to secondary options when needed.

My experience with the monitoring and management tools provided by Azure Database for PostgreSQL has been positive. The logs from the host level to the database itself are very relevant and provide the correct metrics I need, including availability metrics that help me receive notifications when databases are down from the platform perspective.

Regarding security, I find the integration with Defender for Cloud valuable as it offers recommendations on how to harden databases. Features such as private endpoints that restrict access and the role-based access control capability allow me to provide necessary access to people who need to view databases on the portal.

I have not been involved in development, so I cannot share much on improvements or enhancements I would like to see at the moment. I am comfortable with the graphical user interface of Azure Database for PostgreSQL, and the Azure calculator is useful for obtaining pricing information. I cannot mention any improvements at this time.

I have been working with Azure Database for PostgreSQL for approximately one year.

Overall, I find Azure Database for PostgreSQL to be predictable and reliable, as I have not encountered any performance issues with it.

Azure Database for PostgreSQL has proven to be stable regarding scalability. I have not had clients whose workloads need to exceed current capacity, and it appears we are right-sizing well. I have not performed load testing to determine what happens with high CPU, RAM, or storage usage.

I rate the technical support from the Microsoft tech support team as a seven out of ten. I have been in very few situations where I needed to escalate with Microsoft support, as most issues are well covered in the documentation.

I rate it a seven because it sometimes takes a while to receive that first response from them, which may depend on the case. If they could improve response time, especially for critical scenarios, it would be beneficial. The aspect of being charged for technical calls as a Cloud Service Provider also discourages engagement, causing me to seek solutions through the community or internally.

I have not worked with on-premises PostgreSQL databases prior to adopting Azure Database for PostgreSQL.

Since implementing Azure Database for PostgreSQL, I have not seen a client migrate from one instance to another, so I cannot specifically tell you whether there have been any changes in application uptime, but I believe there must be.

I have not utilized Azure Hybrid Benefit with Azure Database for PostgreSQL, but I have used it for SQL and on virtual machines.

Azure Database for PostgreSQL has helped reduce infrastructure costs for my clients, as they pay for what they use and can improve or increase storage whenever needed without having to over-provision resources.

Regarding the pay-as-you-go pricing model of Azure Database for PostgreSQL, for the clients I manage, I utilize reservations for databases, so I have not seen cost issues due to this aspect of cost optimization.

Overall, based on my experience with Azure Database for PostgreSQL, I would rate it a nine out of ten, as I have not faced many challenges with it. The reason for not rating it a perfect ten is that I believe technology requires upgrades and there is always room for improvement. While I have not pictured a certain integration, I think developers could provide better insights if they were more involved.

I do not have the ability to comment on whether Azure Database for PostgreSQL has influenced my application development processes, as I am not in a position related to the development team.

I cannot provide a specific answer on how integrations of Azure Database for PostgreSQL with other Azure services have impacted my overall cloud strategy, as I am not at the decision-making level in my organization. My focus is mainly on delivery.

From my experience with Azure Database for PostgreSQL, I cannot share specific integrations that I find most beneficial, as I have not interacted with it extensively. I believe that would be better feedback from a developer actively developing applications.

My advice for organizations considering Azure Database for PostgreSQL is to embrace observability and monitoring, as I have seen many customers neglect to enable monitoring or log collection. These tools are essential for diagnostic settings and help in observing, managing, and receiving alerts for any issues. I would rate this product a nine out of ten based on my overall experience.

Public 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

We're a managed service provider using Azure Database for PostgreSQL to deliver services to 300 customers, so there are potentially 300 different use cases. We use it as a normal database instead of MySQL or Azure SQL because PostgreSQL performs well, especially with the flexible server. 

We do many things in the cloud with Kubernetes containers, and our customers can use a containerized version of Postgres. We abstract it so that it runs in Azure itself instead of being part of the Kubernetes cluster. It makes sense to go from Postgres to Postgres.

Our organization's database uptime has improved after implementing Azure Database for PostgreSQL, particularly with the flexible server's redundant configuration capabilities, which allow for failovers and read-only configurations. This results in greater resilience and uptime for end customers.

The most valuable features of Azure Database for PostgreSQL are its networking capabilities, which allow for integration with other Azure services. It's easy to configure with the flexible server we used. The newest iterations of Postgres are easier and easier to upgrade.

Azure Database for PostgreSQL can be improved by allowing quicker scaling without blips. It would help if it were more dynamic and required less planning. You can't just scale back performance and storage as needed. Adding flexible scaling capabilities would enhance performance, making it greener and more efficient.  Additionally, addressing the reliability issue where the database might crash during sudden performance peaks would be beneficial.

Azure PostgreSQL's monitoring and management tools are constantly improving, but costs can be challenging. Azure Monitor provides the default metrics, but if you want all the metrics, you need to enable all logging, which will have more cloud costs than the database itself. 

I have been using Azure Database for PostgreSQL for a couple of years.

There is a stability issue where, if the database usage peaks quickly, it may crash and require intervention to restore functionality. It does not auto-heal or self-heal in such situations.

Previously, we used PostgreSQL running in a container on a different platform, not on-premises.

Sometimes, we use Azure technologies for migration, and other times, we use customer technologies. The migration process did not require support from Microsoft.

Azure Database for PostgreSQL has reduced our total ownership cost, but I can't provide the exact figure because it varies among customers. Overall, PostgreSQL is cheaper and more efficient. It offers at least 25 percent cost savings compared to maintaining on-premises databases.

The pricing experience is positive. Azure Database for PostgreSQL reduces the need for hardware investments, and the pay-as-you-go pricing model positively affects database-related costs by allowing us to start small and scale as needed.

I would rate Azure Database for PostgreSQL an eight out of 10. Its scaling capabilities could be improved, and ensuring reliability during sudden usage spikes is needed.

Public Cloud

Microsoft Azure

We have turned on pgvector, which is an extension for the vector search. We use PostgreSQL as the RAG database for the Gen AI application.

We use it as a RAG database. It coordinates our chunks and connects them with the embedded model to organize them into high-dimensional space. The performance of our RAG application is very good. We have 96% satisfaction.

It facilitates AI technology adoption by coordinating chunks and connecting them with the embedded model.

We are a bank. Our information is mainly stored in a SQL database. Azure Database for PostgreSQL offers a way for our colleagues to quickly understand vector search by using the combination of RDB and the vector search extension. This means we do not have to learn vector databases at the beginning. We can just turn on the extension, and it has the vector search right away.

It helps us to retrieve the context. I use it a lot. It is easy to execute an SQL query.

It offers an easy vector search, which is helpful, but does not offer knowledge graph functionalities.

It is easy to use and optimize. It is very easy for us to understand how a chopped chunk can be translated into embedding. We can put some additional value into the chunk itself.

They can offer more RAG extensions. Currently, it only has the vector search. 

It does not presently support knowledge graph functionalities as Neo4j does. It also does not offer some tools to improve indexing the way other vector databases offer.

We have been using it for a year.

The stability seems fine. We have not noticed any issues. We have generative AI applications, and we have not noticed any latency.

It scales well with the workload.

We handle most implementations in-house, without extensive reliance on Microsoft's technical support.

Neutral

We previously used an on-premise PostgreSQL database. Azure Database for PostgreSQL provides a console to monitor PostgreSQL.

We are now considering using Neo4j in parallel for its knowledge graph capabilities.

We do not pay for a full-year subscription because our usage is still at the beginning phase and not much. The pay-as-you-go model works well for us.

I would rate Azure Database for PostgreSQL an eight out of ten.