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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

We have not expanded usage at this time.

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

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

Positive

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

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

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

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

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

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

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

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

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

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.