Azure Database for PostgreSQL Reviews

For the last four years, we have been a huge customer of Azure Database for PostgreSQL. We migrated from a single machine to Flex Server and are now evaluating the elastic capabilities. We are from American Airlines, so we do a lot of price optimization and network optimization. We use Azure Database for PostgreSQL for price optimization and network optimization. This involves large-scale data, which we have traditionally used Oracle Exadata database for in our systems today. When we migrated to Azure, PostgreSQL proved to be very beneficial and performed on par with what Exadata can do.

Azure Database for PostgreSQL has facilitated the adoption of AI technologies in our company's database operations. We were actively considering vector database implementation across NoSQL and other platforms. Since we have expertise with PostgreSQL and experience with PG Vector, we went with the PG Vector extension with Azure Database for PostgreSQL. This enabled us to have all our data stored as a vector in the vector database so that our AI agents can use it.

Azure Database for PostgreSQL has impacted our ability to innovate and stay competitive in our industry. We run an airline, not a technology company, but any innovation we make use of, we put it in the customer viewpoint. This goes into the core of our company. Any technology that comes in, in this case PostgreSQL, helps our developers understand what features need to be used so they can deliver the customer use case much faster. We get the value out faster, and once you get the value out faster, you are ahead of the competition.

The features of Azure Database for PostgreSQL that I prefer the most are Flex, WAL replication, and asynchronous replication between region to region.

I appreciate these features because you don't have to wait for the commits to happen for the data to go to the other region, but you still get the SLA of a similar level. My applications can perform without needing to compromise or fight with the speed of light.

These features benefit our company because we were able to solve some of the latency issues with our applications and still get our RPO met by using that feature. It is really a customer experience win and also an operational win for us.

My experience with the monitoring and management tools provided by Azure Database for PostgreSQL is perfect. We use Azure Monitor to monitor all of it. Out-of-the-box, single-click enablement of all the traces and metrics has really helped us. We also use Azure Insights so we can look at every single query performance, index performance, and other details. It is a turnkey solution for us. We just click a button, enable it, and it is all there.

Azure Database for PostgreSQL can be improved in the area of elastic capabilities. One of the things we were actively looking for is the elastic feature, which was made a GA at this Ignite event. I am really happy that finally in Azure, we have a product which we can use for elastic clusters. If you are bound with a single server, then you have a vertical limit. Now you do not have any limits. As long as your use case grows, we can grow.

The only thing I would maybe be thinking about is we should also allow customers to pick different node sizes for every node inside the elastic eventually. Some nodes do not need that big capacity. So that may be a nice-to-have feature, though it is not a must-have at this point.

We have been using Azure Database for PostgreSQL for the last four years.

Azure Database for PostgreSQL has changed and it has actually improved our database uptime. With the availability metrics, this current database is four nines by default. You guys gave it five nines.

My impressions of Azure Database for PostgreSQL's ability to scale to the growing needs of our company are promising. We have a lot of workload today which we use with Oracle database. Those are all the things which are going to change into PostgreSQL in some form or fashion. We have a multitude of applications which are all using SQL. Eventually, I would envision we have a farm of PostgreSQL servers inside our company.

My impressions of the latency and availability of Azure Database for PostgreSQL are favorable. We designed our system to have a highly resilient system. We do have a DR database and we also have an HA system inside. These things are by design. Azure does provide that capability. It is up to the product or application team to decide whether you need it or not. In our case, we did enable all of that, so we got that resiliency.

The latency and availability aspects were able to meet all our SLAs, which compared to what Oracle was able to provide. We did not have any latency issues at this point.

I would rate customer service and technical support for Azure Database for PostgreSQL to be 10 out of 10 because we received all the things which we needed. It is not about whether I can get support, but whether I need timely support. That is where the differentiation is. We got the timely support. During migration, every day is important. If you miss a day, new issues come and that spills the time over. Cascading effects can happen. The support which we received during our migration was really good, and we were happy about it.

Positive

We used Oracle Exadata.

My experience with the migration process to Azure Database for PostgreSQL, particularly in terms of technical expertise required and any support received from Microsoft is good. Coming from a traditional Oracle Exadata setup, all queries will run faster because Oracle has that optimization layer in between which optimizes it for you, which is why you pay a lot of money for that. When you come to Azure Database for PostgreSQL, that layer is gone. So you might have to rethink your data, how you are going to partition the data, how you are going to index the data, and how you are going to access the data. As long as you know these things, you can get similar query performance in Azure Database for PostgreSQL. The Azure expertise and product team really supported us with a touchpoint call every week for a month to make sure all our access queries are working and meeting our SLA. The Azure product team really supported us over the course of about three months during our migration period to help us get there and then work in production without having any issues.

The migration to Azure Database for PostgreSQL impacted our application code and overall database management because the database management now becomes much simpler. We are not managing anything in the infrastructure layer. The coding part is a very similar thing to how we used it in Oracle. We just wanted to make sure some queries are rewritten to accommodate the new partition way of doing things. Other than that, application migration was a minimal change for us when migrating from Oracle to Azure Database for PostgreSQL.

Azure Database for PostgreSQL has helped us reduce our infrastructure costs. Today, I would not name it as infrastructure cost, but I would call it total cost of ownership. If you own a database, then definitely Azure Database for PostgreSQL might be cheaper compared to any database out there at this point. On top of my mind at this point, maybe 13 to 15 percentage of the cost reduction we can see.

The pay-as-you-go pricing model of Azure Database for PostgreSQL has affected our database-related cost and resource allocation. We started with the pay-as-you-go model because we wanted to give it a try, grow slower and then steady, in a phased approach. We eventually decided that we know what our reserved capacity looks like. So we changed our strategy last year to go buy the reserved capacity, but we started with the pay-as-you-go. This is a really nice entry point for any customer who wants to come and try it. Pay-as-you-go is a really good pricing choice. Once you are comfortable and ready to make some commitments, you get about 30 percent saving if you are going with one-year or three-year reservation cost. We pretty much started with pay-as-you-go, but now we have moved into a reserved cost.

Azure Database for PostgreSQL has influenced our application development process. Most of the developers today have the relational mindset because relational databases have been around forever. Azure Database for PostgreSQL really came in and said the dialect is similar to what a relational PostgreSQL dialect is with a little bit of a change. Any developer who wants to use Azure Database for PostgreSQL does not go through a skill level improvement or need to learn anything new. They apply the same thing they already know. This makes our developers go in and execute the project instead of learning a new skill.

Azure Database for PostgreSQL has helped integrating with other Azure services and has impacted our cloud strategy. We are a heavy Azure shop, so most of our runtimes, everything runs inside Azure. Azure Database for PostgreSQL is a relational database, and every integration, we do not want to customize it. Anything which comes out of the box, we take it and make use of it so that we can deliver faster. Azure Database for PostgreSQL definitely improved our delivery speed because of the turnkey integrations.

The integrations with Azure Database for PostgreSQL that have been most valuable to our company include the Functions App integration, which was really cool. The ACA apps integration was also really cool. All the open-source community integrations from PostgreSQL also really improved our velocity.

My impressions of Azure Database for PostgreSQL security features such as encryption and Advanced Threat Protection are positive. We use the Advanced Threat Protection today in our ecosystem. Every solution which we put together, that really comes in handy. The encryption part, we have not tried it, but we would love to try it for another PII use case. For now, the threat protection is what we use day in and day out. We enabled it and it just works.

Azure Database for PostgreSQL has had an impact on our company's data protection strategy compared to that previous platform. We all have similar threat protection in our database, even in our on-premise systems. By Microsoft Defender in place, Azure Database for PostgreSQL is automatically secured in a way that we do not have to worry about anything else. It completely runs in our network because of the VNet integration. That way we have the data protection, and currently, you have also implemented the Microsoft Entra ID integration. This made our data protection much more secure because we know certain things are only accessed by admins and certain things are not. We are able to get that with your integration today.

We did it with Azure. I would give Azure Database for PostgreSQL an overall rating of 10 out of 10.

I would advise other companies that are considering Azure Database for PostgreSQL that it is the right direction to move in if you are working on a relational database. It is not as simple as bringing a query and having it work as is. There will be some tweaks. The important thing to notice is how you partition the data and how you access the data. As long as you can define that upfront and work with the Azure team, they can help you make sure the migration is smooth. As long as you understand the partition and the access patterns, Azure Database for PostgreSQL will work.

Our main use cases for Azure Database for PostgreSQL are straight up database with the extra support for the JSONB functionality. We have some DocumentDB options out there and some Cosmos as well. Having the best of both worlds with the relational data, but then you can append the schemaless data kind of along for the ride is our main use case. It's mostly structured data, but with the support for the unstructured data that's a first-class citizen, not just a string column in a database.

Azure Database for PostgreSQL has influenced my application development process. I love Postgres now and just the flexibility that it has combined with TypeScript, so I'm in this loosey-goosey world where I can do things quickly and dirty and Postgres helps you with the proof of concept phase where you want to be more quick and dirty, but the features also do scale to our needs for production. The ability to move quickly with the flexibility that the ecosystem offers is all I need. It's very refreshing as a developer.

I have noticed changes in time to market for my applications. For the proof of concept, which we haven't quite shipped yet, absolutely. The flexibility that we have with the JSONB functionality allowed us to get data into the system, build the POC, get it in front of people, and then as we find needs for things to be more normally normalized, we can go back and make those changes. Until then, with the support for all the indexing and everything that you can do within the JSON data in the database, it's very fast for the proof of concept.

The migration to Azure Database for PostgreSQL has impacted my application code and overall database management workflow positively. The flexibility of the tooling around Postgres is remarkable. Postgres is an open community product. The Drizzles of the world being available means I can use those tools where in Azure SQL world with SQL Server, I cannot. The tooling that is built around Postgres allowed us to move much faster because we're in the TypeScript ecosystem for this product, and playing nicely with SQL Server in TypeScript is harder versus Postgres in TypeScript. The tooling around Postgres and the flexibility it offers made it easier in that regard.

The feature of Azure Database for PostgreSQL that I appreciate the most is the refreshing feeling of using Postgres. Coming from Azure SQL, everything that I want there is there, and as a JavaScript and TypeScript developer, Drizzle ORM is the big hotness now. The support from that directly with Postgres has been nice. The integration and the open-source community allowing all the pieces of the puzzle to fit together with wide flexibility is excellent. PostGIS is incredible to have available for the geospatial functionality, although I haven't used it too much. The JSONB functionality is what caught our eye and that's probably what we use the most.

This feature benefits my company at the end of the day because I think it helps to be in the relational database world. Being able to stick into that world of a relational database but also use the features of the JSON support that Postgres offers is basically all we need right there. Best of both worlds for us.

The security features of Azure Database for PostgreSQL that my company finds most valuable include the integration with Entra, which allows us to handle all of our logins in a passwordless way. Pulling out of the passwords so we don't have to share those around and handling it all through Entra without having to worry about it is the main piece.

Azure Database for PostgreSQL can be improved, but I love it so much. I'm such a fanboy these days from the work I've been doing in the proof of concept space has been so great that I struggle to find areas for improvement.

For Postgres in particular, it's fairly new. We've been on Azure SQL for most of the time. This is a pretty new project where the tools including the JSONB support and everything that you get with Postgres have been very useful. We've started to migrate over and this project is the first one within the last three to four months.

The database uptime with Azure Database for PostgreSQL has not changed after implementing it. We haven't really run into issues with Azure SQL either, so either way would have been fine.

The latency and availability of Azure Database for PostgreSQL has not changed. Azure SQL is a similar SKU that's out there. It's just the difference between the posturing, especially in TypeScript and Postgres versus .NET with C# and MS SQL. The flexibility allowed us to pick a different product that had a couple more features. As far as the platform and the offerings from Azure, they're about the same.

The ability to scale workloads with Azure Database for PostgreSQL is adequate. For what we're doing, it's fairly CRUD-y, so it wouldn't be too big of a deal. I've done basic load testing on it and smaller instances of Postgres with caches sitting in front of it, but it fills our needs very cheaply. I think it would scale and the performance of it would be fine for our needs for even just the cheaper SKUs. Our use case isn't as needy as some that are using Postgres. Some of the presentations I've heard discuss the scale that we're not at yet with this application, but maybe could be in the future. We have plenty of applications that need high performance and we're looking into Postgres for those.

I would rate the customer service and technical support as good. I haven't needed it, but I'm confident it's good.

Neutral

I did previously use an on-premise database before. At this company, there's a couple laying around, but generally no. In my past companies, yes.

I did not need any support from Microsoft during the migration process to Azure Database for PostgreSQL. There's been some data migration, but as a developer, I'd rather spend two hours coding something than doing something manually that would take five minutes. So I took two hours and coded something for it. We didn't hit any snags in the process, but what we're using Postgres for at this point is basically a lift and shift. I'm a big JetBrains fan, so I use DataGrip's features to just move things around, but there are a thousand ways to do it and I'm sure I've done every one of them by now. There are probably better ways.

The integration of Azure Database for PostgreSQL with other Azure services has not impacted my overall cloud strategy. It's just the integration is what we're used to from Azure SQL already. The fact that you check a box and everything can talk to each other, whether you have private endpoints or other security needs, it all just works. We're used to that already so we didn't have to think about it. It didn't change our posture, it just emboldened it.

Azure Database for PostgreSQL has not really helped reduce infrastructure costs at my company. It hasn't really increased it either. What we're doing is pretty basic CRUD applications with a nice data model. For the most part, it hasn't really increased the costs because the scale that we need for applications in my space generally isn't that big. It didn't hurt the cost because Azure SQL had more SKU options, so you could go lower or a couple of steps in the middle. Postgres has a few fewer options, but it's between five to fifteen dollars, so it's not really a big deal. No, it didn't really impact the cost at all.

Azure Database for PostgreSQL has affected my database-related costs and resource allocation. There's probably room for improvement on the Postgres side, certainly on the Azure SQL side. We have a lot of large relational databases that I'm sure are fairly consistent in their needs. Moving to reserved instances probably would be helpful and we're probably in a spot where we'd investigate that more now than ever with tariffs and everything that's going on. We're a fairly profitable company, so we've been focusing on moving faster and faster. As time goes along, it's going to be more and more useful. As our usage of Postgres increases, which I'm thinking it will, it will make an impact. Right now the devil we know is pay-as-you-go, so we've stuck with it and it's fine for our needs.

My company is in its first steps in the AI journey at the moment. Copilot adoption is across the board with every developer using Copilot every single day. The autocomplete suggestions are the top feature and the chat is up and coming. As far as the agentic functionality, we're not very far along, but there are a lot of applications where I think it would be very useful. It's coming and there are communities of excellence in place to help move it along, but we are at the beginning of the journey.

Azure Database for PostgreSQL has not yet facilitated the adoption of AI technologies in my company, but I'm attending presentations here to figure out how it possibly could.

My advice to other companies that are considering Azure Database for PostgreSQL is to land back on the idea that a lot of people land on NoSQL because it feels good to say that we're schemaless and it'll fit that. The normalized pattern plus the schemaless data that can ride along with it has been very refreshing to me. I've enjoyed it greatly and I think we have a lot of spots where we are using NoSQL options that have costed us a lot of money because upfront you try to convince yourself that your data is truly schemaless. Even if it is, I think Postgres would be a good way to go about it because then you still get the best of both worlds of normalized schemaless SQL and NoSQL schemaless options as well.

Azure Database for PostgreSQL has probably impacted my data's protection strategy compared to those on-premise solutions. If they were to move, I would feel more comfortable having them in the cloud. We do still have DBAs that are full-time managing those things and there's so few and far between that it probably would be impactful, but not that impactful. It's not the fault of Postgres though. Our posture is almost all cloud already.

I would rate this review a nine out of ten.

My main use case for Azure Database for PostgreSQL is to provide a reliable, scalable, and manageable PostgreSQL SQL database platform for our application workloads. It is primarily used to store and manage application data while leveraging Azure's built-in capabilities for high availability, automated backups, security, monitoring, and scalability.

Our application uses Azure Database for PostgreSQL to store and manage application data such as user information, transaction records, configuration data, and application logs. It serves as the back-end database for our production application.

Regarding my main use case, we also value the managed structure of the service, particularly the automated backups, high availability, security, and easy scalability, which helps to reduce database administration and operational overheads.

The key features we value in Azure Database for PostgreSQL are high availability, automated backups and point-in-time recovery, scalability, strong security, private networking, monitoring, and reduced database administration through the fully managed service.

Availability has had the biggest impact for our team, as it helps us keep our database available during infrastructure or server-level issues and reduces the risk of application downtime. It also gives our team more confidence in running critical workloads without having to manage the underlying database infrastructure and failover processes ourselves. This has reduced operational effort and allowed the team to focus more on the application support and development rather than the database availability management.

Overall, the combination of high availability, automated backups, security, and scalability makes this service reliable and easier for our team to manage.

Azure Database for PostgreSQL has positively impacted our organization by helping us improve reliability and simplify database operations. The managed service reduces the effort required for infrastructure maintenance, backups, patching, and availability management. It also gives us the flexibility to scale as application requirements grow while providing a secure and stable platform for our production workloads. This has allowed our team to spend more time on application development and business requirements instead of routine database infrastructure management.

Azure Database for PostgreSQL is already a strong managed service, but the user experience could be improved further through simpler cost and performance optimization guidance, more detailed monitoring and troubleshooting insights, and easy configuration management. More proactive recommendations for capacity planning, query optimization, and resource utilization would also help teams manage production workloads more efficiently.

Better integration with third-party monitoring and IT management tools would be helpful. More detailed troubleshooting guides, practical deployment examples, and faster support for complex production issues would also make the service easier to manage.

Azure Database for PostgreSQL has been stable for our workloads. We have experienced consistent performance and availability with the managed platform, reducing infrastructure-related issues and routine maintenance overhead.

Azure Database for PostgreSQL has provided good scalability for our workloads. We can increase compute and storage resources as application usage and database volumes grow without having to provision and manage additional database infrastructure ourselves. This flexibility helps us accommodate peak workloads and future growth while keeping the operational effort relatively low.

Regarding Azure Database for PostgreSQL's ability to scale workloads, the experience has been positive. It provides the flexibility to increase compute and storage resources as application workloads and data volumes grow. This allows us to handle changing demand without having to redesign the underlying infrastructure or provision new database servers manually. The ability to scale resources through Azure also makes capacity planning and workload growth easier to manage.

Customer support for Azure Database for PostgreSQL has been generally positive. It is helpful for troubleshooting production issues. The documentation and technical resources are also useful for resolving common issues.

We did not use any other solution prior to Azure Database for PostgreSQL.

Our migration experience to Azure Database for PostgreSQL was generally smooth, although it required PostgreSQL and Azure expertise for planning, compatibility checks, and data migration, also applying to the application connectivity. Microsoft provides useful documentation and migration tools, which helped our team during the process. Having Microsoft support available for technical issues and troubleshooting also provided additional confidence, particularly for production migration activities.

The migration to Azure Database for PostgreSQL required some application configuration changes, mainly around database connectivity, connection settings, and validating PostgreSQL compatibility. From a database management perspective, the workload became simpler because Azure handles mainly infrastructure-level tasks such as backups, patching, availability, and monitoring. This reduces routine administrative work and allows the team to focus more on application and database optimizations.

I have seen a positive return on investment through reduced operational effort rather than direct headcount reduction. Based on our experience, the managed service saves approximately hours of database administration effort per month by reducing manual work related to backups, maintenance, patching, monitoring, and availability management. This allows our existing team to spend more time on application development and higher-value database activities.

My experience with Azure Database for PostgreSQL's pricing, setup cost, and licensing was generally positive. Since Azure Database for PostgreSQL is a managed service, there is no separate PostgreSQL software license or major upfront infrastructure investment required. The pay-as-you-go model provides flexibility to align cost with our usage, while the main consideration is monitoring compute, storage, backup, and networking costs to keep the overall deployment optimized.

Before choosing Azure Database for PostgreSQL, we evaluated a few alternatives, including running PostgreSQL on Azure virtual machines, using a self-managed PostgreSQL environment on-premises, and other managed cloud database options. We ultimately selected Azure Database for PostgreSQL because it provides the PostgreSQL compatibility we needed along with managed backups, high availability, and reduced infrastructure administration.

My impressions of Azure Database for PostgreSQL's latency and availability have been positive. Database response times have been consistent for our workloads, and the service provides reliable availability through its managed infrastructure and high-availability capabilities. We have also found that keeping the application and database within the same Azure environment helps maintain predictable network performance and reduces connectivity-related concerns.

Our overall impression of Azure Database for PostgreSQL's security features is positive. Encryption for data at rest and in transit, private networking, identity and access controls, and centralized monitoring have been particularly valuable for us. These capabilities help protect sensitive database information while giving our team better control and visibility over access. The integration with Azure's broader security ecosystem also makes it easier to apply consistent security policies across our cloud environment.

Azure Database for PostgreSQL has influenced our application development process by simplifying it through providing a managed PostgreSQL environment that developers can provision and integrate with applications without managing the underlying database infrastructure. For example, development teams can focus on database schemas, queries, and application functionality while Azure handles routine maintenance, backups, and availability. This has helped reduce setup and operational effort during development and deployment.

Since adopting Azure Database for PostgreSQL, we have noticed some improvement in time to market for our applications. Since the database is managed by Azure, our development team spends less time on infrastructure setup, database maintenance, backups, and availability-related tasks. This allows them to provision database environments and focus on application development and testing more quickly, thus bringing an improved application towards production faster.

Our experience with the monitoring and management tools provided by Azure Database for PostgreSQL has been positive. Azure provides useful visibility into key metrics such as CPU, memory, storage, connections, and database performance, which helps us identify potential issues early. The centralized Azure portal also makes it easier to manage configurations, backups, scaling, and availability. Overall, these tools have reduced the amount of manual effort required for monitoring and database administration. The primary audience is our application development and IT operations team, including database administrators and the infrastructure team responsible for managing, monitoring, and supporting production applications.

Integration with other Azure services has positively impacted our overall cloud strategy. For example, we can connect the PostgreSQL database with Azure application, networking, monitoring, security, and identity services within the same cloud environment. This simplifies management, improves integration between application components, and reduces the need to maintain separate platforms for different workloads.

The most beneficial integrations have been with Azure networking, monitoring, identity and access management, and application services. These integrations help us maintain secure connectivity, monitor database performance, manage access centrally, and provide a smoother connection between our applications and Azure Database for PostgreSQL. They also have reduced the need for separate management tools and manual administration.

We have seen an improvement in database uptime after implementing Azure Database for PostgreSQL and overall service reliability. The managed platform, automated maintenance, backups, and high availability capabilities have reduced downtime caused by infrastructure and routine maintenance activities. We have not measured an exact percentage improvement, but the reduction in operational interruptions has been noticeable. The impact has been positive, mainly through improved availability and fewer service interruptions. Automated maintenance, backups, and high availability capabilities have reduced the need for manual intervention and helped maintain more consistent database availability.

My overall rating for Azure Database for PostgreSQL is 8 out of 10.

Azure Database for PostgreSQL is included in our SaaS solution. It is one of the components of the SaaS solution built by us.

Azure Database for PostgreSQL is deployed for all our customers, making it a key component for us. All our Microsoft users are using this solution, so it is a key one.

Azure Active Directory integration for security is used.

The features of Azure Database for PostgreSQL are fully transparent to me, so I cannot provide specific areas for improvement.

PostgreSQL extensions for analytics have not been utilized, and I have not heard about this capability.

I do not know how horizontal scaling has helped manage workloads.

I cannot determine how Azure Database for PostgreSQL can be improved or what additional features would be desired; there may be some pain points that would be helpful to address.

Since starting six years ago, Azure Database for PostgreSQL has been used.

I assume the stability and reliability of Azure Database for PostgreSQL is strong; otherwise, we would not use it. That is the main concern. We will not take any risk, so it needs to be truly resilient, available, and scalable.

Every year and every quarter, new releases are made with many new features, and everything is based on Microsoft solutions.

If a company decided to go through Azure Database for PostgreSQL, it should be a 10 out of 10 solution; otherwise, they would take another solution on the market. The overall review rating for this solution is 10 out of 10.

I particularly don't use the features of Azure Database for PostgreSQL; I just create it, make sure everything is secured, and ensure it's secure as per our environment. But I'm not physically going there and using it. I just use it to make sure the particular PostgreSQL is secure, and I appreciate the navigation and documentation. Whenever I'm using a new product, I look for the documentation because I want to know what's going on. With PostgreSQL, the documentation is perfect, and using it on Microsoft is easy because there is documentation for Microsoft PostgreSQL, which I find easy to follow.

My experience with the monitoring and management tools provided by Azure Database for PostgreSQL involves sending all the logs to Azure Sentinel; we enable diagnostic settings and send our logs to Azure Sentinel. We prefer managing all our logs related to any tool, whether it's on-premises or cloud-based, then we use syslog to send it to Sentinel. We enable diagnostic settings on every service, and we have policies to auto-enable the diagnostic settings, and all the logs go to Sentinel. Meanwhile, we filter some of the unwanted logs, such as audit logs, which we don't need all of.

Azure Database for PostgreSQL definitely influences our application development process, especially since we have a team of developers who are continuously trying to play with the latest products and keep up with what's going on with our competitors. We use this database, and not just PostgreSQL; we also try multiple other databases provided by Azure, but so far, PostgreSQL has been easy. I don't want to name them, but we have tried other databases; however, there is a learning curve. Instead of trying to teach a developer or a person on learning that, since PostgreSQL has been around for a while, most of our developers prefer using it.

Azure Database for PostgreSQL definitely helps me reduce my infrastructure costs, and it gives me an idea and exposure of what everybody is doing because we have logs enabled, alerting set up, and we are monitoring it. We make sure everything is secure because security is always our main parameter.

I would add that from my perspective, Microsoft technical support isn't great; we have tickets sitting in the bucket. It depends on the license you have; with the E5 license, we don't have Microsoft security support. However, in my previous role, Microsoft support was part of the license, so we got immediate responses, and it was pretty quick. It's not that the support engineer has an answer immediately, but they did work on the issue, consult other engineers within their company, and provide the support.

From one to ten, I would rate Microsoft technical support a six, highlighting that they could improve their support system.

Neutral

Azure Database for PostgreSQL has not influenced our overall cloud strategy.

My advice to other companies considering this solution is to ensure there is good documentation and that the documentation is updated frequently. Without it, it's tough for a person. As a security engineer, I have to explore all the Azure resources that my company is interested in, whether it be a POC, pilot, or POV. If there isn't enough documentation, then it's tough for me to approve it. The business wants me to approve it, but as an engineer, I have to approve the service. How am I going to do it without proper documentation? Scheduling a call with the vendor will take a lot of time, but if there is documentation available, I can just rely on it, create some test resources, and test it out by myself, saving me a lot of time.

I rate this solution an eight overall.

Currently, for Azure Database for PostgreSQL, we are seeing that many of our customers in the education and nonprofit sectors are looking for a more easily consumable way to work with their data. When you consider those two industries, they are not about high spend, but about maximizing credits and consumption when it comes to being able to compartmentalize and publicize data.

Azure Database for PostgreSQL is a foundation before any type of thoughts could even be considered in the AI space.

My impressions of Azure Database for PostgreSQL security features, such as encryption and Advanced Threat Protection, are that these represent the number one requirement in terms of why our customers would invest in that space. Those specific feature components are a requirement based on the data that they are actually trying to publicize, ensuring that there is no level of security threat that results in that data being exposed.

My experience with the monitoring and management tools provided by Azure Database for PostgreSQL includes a lot of the internal reports that come through, which I call the out-of-the-box functionality. Much of that is also something that I know my developers will do with customized reports. However, they do serve as the foundation of the out-of-the-box capabilities.

Azure Database for PostgreSQL has influenced our application development process. When it comes to customer requirements, it is typically a need that we see in the space. Thus, when they think about influence, it becomes one of the key requirements in order to actually drive that solution model and architecture in the back end.

Azure Database for PostgreSQL can be improved when it comes to the marketplace. Building trust with AI is the level-set foundation where we are today, with all of the models that are constantly changing. Every model that continuously gets updated means we continue to have to educate, communicate, and be transparent with how that is also impacting what we have turned on with the current state models, and that obviously impacts what we have in the database. Unfortunately, this is a constant movement. Setting up transparency and trust with customers who are on it is key, and being able to retest and continuously drive on those solutions is key when it comes to data that is in there.

Customer service and technical support regarding Azure Database for PostgreSQL could always be improved. However, I think it always helps when customers work with partners that have what I consider a backdoor into Microsoft, where you can escalate some calls. In general, any type of customer service from Microsoft is better than none for a lot of other companies.

I have been using Azure Database for PostgreSQL for over the last five years, but my company has been working in this space for over ten years.

I have not noticed any changes in time-to-market for our applications.

Regarding database uptime, I would not have a good answer for that concerning Azure Database for PostgreSQL because that is part of what I consider post-implementation support, and we typically, at least as a partner, drive a lot of that implementation migration. It would be follow-ups that I do not have any data on. In terms of post-solutions, we typically do not do a lot of maintenance, as ownership goes back to them.

My impressions of the latency and availability of Azure Database for PostgreSQL is that it is a concern that arises post-migration.

Customer service and technical support regarding Azure Database for PostgreSQL could always be improved. However, I think it always helps when customers work with partners that have what I consider a backdoor into Microsoft, where you can escalate some calls. In general, any type of customer service from Microsoft is better than none for a lot of other companies.

Neutral

Azure Database for PostgreSQL has not helped to reduce our infrastructure cost as a firm, but it has definitely done so for our customers.

In terms of the pay-as-you-go pricing model of Azure Database for PostgreSQL, this is a complicated answer to come through because it requires looking at that end to end where this is computational versus storage. When it comes to a lot of IT administrators and department owners, they are always looking at all of the factors when it comes to Azure consumption.

Azure Database for PostgreSQL is hugely discounted and cost-effective compared to the previous expenses for maintaining an on-premises PostgreSQL database. That is the number one reason why people are even on-prem.

When considering Azure Database for PostgreSQL and comparing it to AWS, a lot of it comes down to cost, more than anything else.

I cannot speak to which feature I appreciate the most; that is more of what my developers would probably be able to provide input on.

Our customers would say that the migration process to Azure Database for PostgreSQL is obviously complicated, just because for them, this is an area that they are unfamiliar with and not experts in. However, as a partner, this is exactly what we have been selling.

Azure Database for PostgreSQL is a foundation before any type of thoughts could even be considered in the AI space.

I would not say that the integration of Azure Database for PostgreSQL with other Azure services impacted my overall cloud strategy.

Overall, I would rate Azure Database for PostgreSQL as the number one requirement choice for our nonprofit customers and in the education space. It is a must and not a nice to have.

My primary use case for Azure Database for PostgreSQL is migrating our traditional SQL 2012 into PostgreSQL purely for cost savings.

The features of Azure Database for PostgreSQL that I find most valuable are that we are using it as a relational database. We are using T-SQL and I am trying to determine whether we are using the native JSON capabilities.

We do use Azure Active Directory integration for security. The significant benefit of using Azure Active Directory integration for security is that we can use managed identities. This eliminates the need to constantly rotate usernames and passwords, which provides substantial cost savings for us.

I am uncertain about how Azure Database for PostgreSQL can improve. We are still very new to this platform, so I do not yet understand how long-term retention backups, backup situations, and point-in-time restores function. One feature that would be beneficial is real-time regional replication with write-write, always-active capabilities across both coasts regions for our disaster recovery needs. I do not believe that capability exists yet. Currently, we have to maintain a hot spare rather than an active-active configuration.

I have been using Azure Database for PostgreSQL for less than a year.

Regarding the stability and reliability of Azure Database for PostgreSQL, we are still in the development and quality assurance phase. We have not migrated to production yet, which is scheduled for next month.

We do not use a significant amount of horizontal scaling. For Azure Database for PostgreSQL, we have scaled it down quite substantially, so we do not have much load going to it.

Regarding how well Azure Database for PostgreSQL scales with the growing needs of my company, we are still scaled down significantly, so I cannot determine this yet. It appears that it will function adequately.

When evaluating customer support for Microsoft products, the licensing model for support cases changed approximately a year and a half ago when they eliminated the EA support that was included in the EA agreement and started charging for it. When we contacted our EA provider, they informed us we had no option to add it to our EA agreement and we had to move to a CSP. This has been a significant challenge. We experienced trouble with our CSP and had to change CSPs because we could not get the level of support we needed from them. We had always had excellent experiences with our EA, and not being able to add a subscription to support for EA was a major issue.

Considering my feedback on a scale of one to ten, I would place their support now at a four, which is quite poor. Every time I have engaged with Microsoft at their level, it has been wonderful and I had a good experience. I did not want it to change. Quota issues were resolved relatively quickly during the EA days. The support was much better then. This may be related to our CSP being inadequate, but we went from one problematic CSP to another one possibly.

Neutral

I considered competing databases when deciding to go to Azure Database for PostgreSQL. We briefly examined MongoDB and Cosmos DB, but our requirements called for a relational database. Azure Database for PostgreSQL was the only cost-effective option we had for a relational database.

My experience with deploying Azure Database for PostgreSQL has been quite seamless. There was some confusion around the flexible server versus standalone PostgreSQL options. There was a minor oddity with the extension that we needed to add, specifically the UUID OSSP. The confusion was regarding where to find it. Once I located it, it was relatively easy to find. It would be beneficial to have the option to enable certain Azure extensions during the initial build rather than having to build it and then redeploy the extension. Enabling some of the Azure extensions during the machine build process would be a great improvement.

We are still relatively new to Azure Database for PostgreSQL, but based on how much it saves us compared to our Azure SQL costs, I would estimate approximately seventy-five hours annually in operations time and personnel management, including ensuring maintenance occurs during off-hours and coordinating with Key Vault.

Our experience with pricing, setup cost, and licensing of Azure Database for PostgreSQL is that the decision came as a requirement from the development team. We chose it because it is more cost-effective than Microsoft SQL.

I have not utilized PostgreSQL extensions for analytics. The only PostgreSQL extensions we have used so far are the OSSP ones. I cannot definitively state whether we have seen a benefit from enabling the UUID extension that the developers requested, as we have not yet verified any tangible benefits or cost savings.

Automatic patching and backups have a huge impact on my database management strategy. We have an operations team of two people and do not have time to handle database maintenance manually. We chose platform-as-a-service for this reason.

I would rate this product nine out of ten overall.

My main use cases for Azure Database for PostgreSQL are application support, mostly integration with applications.

Azure Database for PostgreSQL has been able to influence my application development process or my customer's application development processes by knowing that at least the forecasted performance you will get out of the database, it becomes a top choice. When thinking about it from a business requirement perspective and forecasting or estimating the tools you want to implement, it comes to mind because of the out-of-the-box experience around performance.

What I appreciate most about Azure Database for PostgreSQL is its performance; I would say that is probably its speed and performance and how it interacts with applications.

The performance of Azure Database for PostgreSQL is very good because compared to other databases, an application talking to a database depends on performance and reaction time being very important. What I have found with client feedback is that it is stable from where it used to be, an evolution. In terms of application responsiveness, it is excellent.

The integration of Azure Database for PostgreSQL with other Azure services has impacted my overall cloud strategy in a positive way. Azure Database for PostgreSQL is a critical component of a whole strategy. Considering that it is part of that whole strategy, it has been very impactful. However, it is not the only thing. When thinking about a strategy or a product, a product is more than just a database. The database is an integral part but the product has to do with the logical layer, the application, the data, and the security aspect, the foundational aspect like the infrastructure and so forth. It is definitely an integral part of the whole holistic toolset or component.

The scalability ability of Azure Database for PostgreSQL is able to scale big workloads. That is the reason why it is at its maturity level now and is a go-to database. The kinks have been worked out over the years. It is at a stage where it is a go-to solution when thinking about scaling across regions and scaling from a performance perspective, horizontal scaling is available.

I am not sure how Azure Database for PostgreSQL can be improved from my perspective. It is not still there from my purview, so it is not really a fair assessment because to me, before it becomes a trend, I have to see it in action or see either the good, bad or ugly over a few instances. I really cannot comment yet on that because it is still at infancy, at least for me.

I do not know if there is anything I would enhance of what is already existing within Azure Database for PostgreSQL. It is a database, and it is always nice to be more reactive in terms of performance. Performance is an evolution. As you are gracious for performance today, it becomes the standard and becomes the new bottom. It is almost as though we crave for more, and it is how we live as a society. What is considered excellent today, if you stay there as an innovator as Microsoft, it will become stale tomorrow. The simple answer is yes, the industry always craves the next advancement. What is better? Make it faster, make it more reactive. That would probably be my answer there.

The performance of Azure Database for PostgreSQL is very good because compared to other databases, an application talking to a database depends on performance and reaction time being very important. What I have found with client feedback is that it is stable from where it used to be, an evolution. In terms of application responsiveness, it is excellent.

I do not see any negative aspects from what I have seen of Azure Database for PostgreSQL platform. It has come a long way. There were some concerns around performance years ago. For the last few years, I have not heard anything. It is the go-to database if seeking performance and capacity. Bug fixes and such things are not really top of mind as an architect or for my clients as decision-makers. They do not think about whether something may not work or whether it is faulty. I think we have passed that stage in terms of concerns around performance and security. It is more about what is the art of the possible? What can we do with this database? What is out there? What is new? What else is Microsoft working on?

I have not seen any negative aspects regarding the latency and availability of Azure Database for PostgreSQL. I have not heard anything. It is keeping its SLA. There have been other challenges at least a few weeks ago on the Microsoft front. However, Microsoft's ability to turn things around relatively quickly and being very transparent to its customers on shortcomings is positive. I think we are in a stage now where we do not worry about resiliency and disaster in the cloud as much. Some business stakeholders are thinking about it here and there, but overall we know that once in a while we are not expecting it to happen a lot but once in a while things may go south in the cloud. We trust and believe that Microsoft has the capability to quickly rebound.

I have not had any chance to have experience with the customer service and technical support of Azure Database for PostgreSQL. That is not really because of a particular reason; my team is pretty good at navigating the Microsoft product system and the technical nuances of Microsoft.

Neutral

The security features of Azure Database for PostgreSQL are good out of the box. I do not know if to say if it is good compared to what, as it is a native product. It is a great product in terms of out-of-the-box security. I have not heard any issues. We have not seen any hacks or any compromise to the product over many years. Overall, security is just out of the box and not so much a concern; it is more so how best you integrate it with applications knowing that it is feature-rich from a performance perspective and how it reacts to applications. Security is not really a challenge from what I know from feedback from developers.

It is a bigger conversation regarding changes in time to market for applications or customer applications. The database is definitely one of the factors, but it is holistic. It is the application itself, its logic layer, it is the company's strategy around the data, the application and user experience. I would not say this is just a singular element. It is hard to say or answer that question.

Azure Database for PostgreSQL has facilitated the adoption of AI technologies in my company's database operations. That is an evolution. For the client base that I serve, they are not quite there yet where Azure Database for PostgreSQL is specifically called out. They are mostly in the early adopter stage when it comes to AI and it is mostly a focus on data readiness, understanding data governance and data structure.

Azure Database for PostgreSQL impacts the ability to innovate or stay competitive in an industry. The art of the possible of the tool, the AI features would definitely be a plus for organizations moving to AI, enabling competitive advantage. I would say it is not even competitive advantage only. It is performance to get speed to market eventually. AI is almost the foundation to any success going forward. It is not just the buzzword. I see it as the heartbeat to the future. Anything that is AI capable or AI embedded would definitely be a step forward to success.

Azure Database for PostgreSQL has not helped reduce infrastructure costs for me or my clients. The database has not reduced infrastructure cost; databases are costly in general. What we appreciate in the industry is some right sizing of the cost or some consideration around cost. But in general, it is a cost element. There are other aspects of the holistic solution where opportunities to reduce cost can be found, but anyone in the industry would say that going down that path will require spending money on database. What we appreciate is that it has been offered as lean and considerate as possible from Microsoft.

Regarding the pay-as-you-go pricing model of Azure Database for PostgreSQL, it depends. If there is an opportunity to lock in pay-as-you-go versus reservation, it depends on your business model. At the end of the day, it depends on the business outcomes you are seeking for the application or the database. You have to forecast where you will be tomorrow, next week, next year, and lock in accordingly. Pay-as-you-go would work for various use cases. If you just need the application for two months, pay-as-you-go is fine. If you need to be locked in for a few years and it seems right-sized for exactly what you need, reservation is the way to go. It probably seems like a conflicting answer and conflicting question because again, it is part of a holistic solution. The database is just one; it cannot stand alone. The database is nothing by itself but it is definitely important. The answer is it depends on the use case.

I do use Azure Hybrid Benefit, and I think my clients have seen benefits when they access this feature. The ones that are already consuming licenses from the legacy strategy, they see a lot of benefits in leveraging the program. That is also serving as an encouragement to move to Azure from on-premises or in a hybrid situation. Overall, it has been positive for clients. It is something that service providers have to educate clients on. It is there but it is up to us to bring that knowledge and the benefits to the client. Azure Hybrid Benefit is out there and something that clients should make use of, but I think the education level on the client side is not there yet. It is really up to providers, not just hybrid benefit, but incentives in general. The more we are educated about incentive programs, the better it will be for us articulating to clients and also better to bring clients to the cloud or encourage clients to venture elsewhere. If they have moved to the cloud just in pockets, maybe just a fraction, but knowing about these benefits, especially migration benefits or consumption benefits, it will accelerate innovation or move to Microsoft.

Regarding uptime, Azure Database for PostgreSQL has been able to change the uptime of the application. It depends on application architecture and how the overall architecture is designed or the application is designed. That is a loaded question because the database is a standalone component of a holistic application. The database could be all resilient but other aspects of the application could fail. It is not fair to blame the database for the application's uptime.

My advice to other companies that are considering Azure Database for PostgreSQL is that it is one product that comes as a result of a bigger conversation from a strategic business alignment perspective, application architecture and application requirements. It should be highly considered. It is scalable, high performance, and resilient. We have not seen any issues over the years. It is matured and has worked out all the kinks that it used to have years ago. If a client is looking to check these boxes—performance, speed, reliability, and resiliency in general—knowing that it will satisfy application needs not just today but in the future, it is definitely a choice. I would rate this product a 9 out of 10.

As an infrastructure platform engineer, I deploy and administer the databases to be used with our security apps as well as some customer-facing applications.

Since I do not do any development, the integration of Azure Database for PostgreSQL with other services impacts our application development by focusing on AI, and we utilize Copilot for everything and anything we can to secure and support our customers.

I assess the impact of automatic patching and backups on my database management strategy by noting that they have saved us time; anything automatic is a blessing. It allows us to be hands-off, and the reliability has been very good with it.

We are in the process of expanding usage by migrating off of MySQL to PostgreSQL for several security applications, and it is going very well; once the database is up and we have all our scheduled jobs or tasks in place, it pretty much runs hands-off.

The benefits of these features to our organization include ease of use, automation, and cost savings.

I appreciate the high availability, the ease of management, and the supportability of Azure Database for PostgreSQL the most.

With the recent changes in Entra ID, authentication has helped my organization by allowing us to audit and track individual users using the databases instead of trying to figure it out based on the group name.

I believe Azure Database for PostgreSQL can be improved by allowing features that are only enabled or configured during creation to be configurable without redeploying the entire database, a process which can impact our customers if it involves an application outage.

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

I assess the stability and reliability of Azure Database for PostgreSQL as being very good for us; although there was an issue related to our network configuration and dynamic DNS, the failovers during regular Microsoft maintenance windows have saved us a lot of headaches and improved stability.

I have not experienced any downtime, crashes, or performance issues; it has been very stable.

We have not implemented any horizontal scaling to this point, but I look forward to the newly released PostgreSQL feature that just came out to provide additional redundancy and scaling.

Azure Database for PostgreSQL scales very well with the growing needs of my organization, and the auto-scaling for expanding disks or adding CPUs is a nice feature that prevents panic.

I evaluate customer service and technical support as very good; we have opened several tickets, and they are very responsive and usually pretty knowledgeable.

On a scale from one to ten, I rate customer service and technical support a nine because they are quick in responding and in working with me to rectify any issues we come across.

Positive

Prior to adopting Azure Database for PostgreSQL, I was using MySQL and SQL Server to address similar needs.

My experience with deploying Azure Database for PostgreSQL has been good for the most part, despite a couple of challenges; we do a lot of automated deployments using Azure DevOps and Bicep, so once I have the configuration file set, it is pretty straightforward.

What worked well in our deployment was the ability to configure many of the server parameters based on the application needs through the portal, and the auto-scaling is another great feature.

I have seen a return on investment with Azure Database for PostgreSQL, as we have been able to migrate databases out of other platforms such as MySQL to PostgreSQL, which frees up cost and saves money through ease of administration.

My experience with pricing, setup costs, and licensing for Azure Database for PostgreSQL is positive; I appreciate it all. The pricing is very cost-effective and stable given that we have many database products.

Before selecting Azure Database for PostgreSQL, I considered Azure MySQL, Azure SQL, and Cosmos DB, depending on the application and the integrations available.

In my evaluation process, what stood out positively was the attractive cost and ease of administration of Azure Database for PostgreSQL, allowing configuration through the Azure portal rather than the native tools; negatively, the requirement to recreate settings during initial creation is time-consuming.

My advice to other organizations considering Azure Database for PostgreSQL is to ensure they know the configuration settings they will need in the future and understand the security ramifications of certain settings, because if they do not turn it on, they will have to rebuild. I rate this product a nine overall.

I have been using Azure Database for PostgreSQL for almost one year. My use cases for Azure Database for PostgreSQL include using it for my day-to-day data engineering purposes, as I am a data engineer and need to use it. It is useful for applications that depend on Agent SQL jobs, Link Server, and cross database queries, handling the queries to get the SQL queries.

The best aspect of Azure Database for PostgreSQL is that it is automated, featuring automated backup, security features, and compatibility with SQL server workload, being very useful for organizations planning to migrate to the cloud with minimal application changes.

Azure Database for PostgreSQL has influenced my application development process as it is used for modern web and cloud native applications, helping in many programming languages such as Java, .NET, Python, Node.js, and PHP, providing flexibility and a rich ecosystem of extensions while easily integrating with Azure services, making deployment and management easier, with high availability and an automated backup facility improving application reliability.

The integration of Azure Database for PostgreSQL with other Azure services has improved our overall cloud strategy by reducing database administration effort through automated backup, patching, and maintenance, enhancing reliability and scalability, and providing performance visibility through monitoring and diagnostic tools while lowering operational overhead compared to managing on-premises database infrastructures.

I would like to see improvements in Azure Database for PostgreSQL, such as more built-in performance tools, automated troubleshooting for complex performance issues, enhanced monitoring dashboards for faster root cause analysis, greater visibility, additional automation for scaling recommendations, and more integrated reporting capabilities.

I have been using Azure Database for PostgreSQL for almost one year.

After implementing Azure Database for PostgreSQL, our database uptime has improved significantly thanks to built-in high availability reducing unplanned downtime, faster recovery capabilities, and better monitoring and alerting which make planned maintenance easier and improve service reliability.

Azure Database for PostgreSQL's ability to scale workloads is straightforward, allowing scaling based on workload requirements, supporting compute and storage scaling, handling traffic spikes without major infrastructure changes, being suitable for both small and enterprise scale workloads, and maintaining consistent performance while reducing operational complexity.

I have not experienced technical support from Microsoft regarding Azure Database for PostgreSQL, but I have heard they have responsive and helpful support engineers that guide configurations, performance, connectivity, and migration issues while prioritizing critical incidents, and their extensive documentation is useful for self-service troubleshooting.

I do not have any experience migrating from on-premises PostgreSQL database to Azure Database for PostgreSQL as I worked on the same premises.

The security features in Azure Database for PostgreSQL, such as encryption and advanced threat protection, mean the data is encrypted at rest and in transit, with Microsoft Entra ID supporting centralized identity management and network security enhanced by private access, VNet integration, and firewall rules, along with RBAC roles for managing permissions and automated backups protecting against data loss, all contributing to improved visibility for security-related activities.

Azure Database for PostgreSQL facilitates the adoption of AI technologies by improving database monitoring and performance optimization, providing recommendations to identify slow queries, offering predictive analytics for workload trends and capacity requirements, and assisting in anomaly detection by identifying unusual database behavior.

My experience with the monitoring tools in Azure Database for PostgreSQL includes query performance insight, allowing me to use extensions such as pg_stat_statements to help analyze query performance and execution statistics, providing visibility into database health and workload behavior, and monitoring being centralized through the Azure portal, with Azure Monitor being the primary tool to monitor CPU, memory, storage, connections, and overall data performance.

In terms of latency, Azure Database for PostgreSQL provides very low and consistent latency for most workloads, relying on application design, query optimization, and network connectivity, resulting in generally consistent response times when the database is properly sized and optimized.

I would definitely recommend Azure Database for PostgreSQL because it has many advantages for modern applications and enterprise workloads, including its open-source nature reducing licensing costs, large community support, extensive ecosystem, and robust security, backup, and high availability features, resulting in a good balance of performance, scalability, security, and cost efficiency. I would rate my overall experience with Azure Database for PostgreSQL as an eight out of ten.