What needs improvement with Azure Database for PostgreSQL?

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

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

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

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.

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.

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.

When it comes to network integration, we always try to have everything in a private network. There were different options on how you can deploy it, and it was a bit difficult to understand what the right option was for us. It's not so easy to replicate it to another region or something of that nature. At least, the last time I had my hands on it was one or two years ago, so perhaps things have changed.

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.

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.

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 don't know if I'm the right person to address how Azure Database for PostgreSQL can be improved. Most of the time, I create a PostgreSQL database, test the policies, and if I'm not using it, I turn it off to save costs until I've tested all my policies. I don't assume myself working on it for more than two or three hours. We did explore multiple databases offered by Microsoft on the Azure platform, but I would say PostgreSQL is still not that expensive compared to other databases. I couldn't recollect any specific areas for improvement.

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 am not certain if Azure Database for PostgreSQL helped reduce infrastructure costs because we are in the process of migrating to the cloud. Our on-premises cost and on-premises infrastructure cost is fixed, and we pay an annual fee to the data center. Once we migrate to Azure, I could check the cost bill, but I have not yet. This is not my main responsibility. The management definitely did an estimate, and I think it will probably save some money for them, which is why they chose to migrate. That is my assumption. I am not a DBA, so for my experience with Azure Database for PostgreSQL on the database side, I do not know if it has certain capabilities. The most significant thing I do and communicate with our DBA about is performance tweaking. I think we still have to do it regardless because you still build on a server with the OS level on it. I do not know if in the future the database will have its native OS layer instead of using Microsoft and dynamically assign the CPUs and memories based on the transaction or task it is running. This could save us some time so it does not have to use sysadmin's time to constantly tweak and assign the CPU. Currently, most databases will try to use all the CPUs available and use all the memories available. We try to give all the databases one hundred percent of the hardware capacity, but sometimes because the OS layer itself will need some resources. If the database used everything, when we try to remote to it, sometimes you will just see a black screen. If we can make this better, why not?

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.

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

Support can certainly get better. I have had mixed experiences a lot of times. About 18 months ago, I had a fairly troublesome time with support. After raising multiple escalations, I think it has gotten a little better.

Performance is one area that has constraints for our customers. I believe there could be improvements in the mirroring part and Change Data Capture (CDC).

There aren't any notable areas for improvement that I could see. PostgreSQL was self-sufficient with no need for additional database knowledge to maintain it.

Perhaps a minor improvement could be made in simplifying user additions, allowing for an easier process rather than scripting it out. However, scripting is not a significant issue.

They can offer more RAG extensions. Currently, it only has the vector search. It does not presently support knowledge graph functionalities as Neo4j does. It also does not offer some tools to improve indexing the way other vector databases offer.

Azure Database for PostgreSQL can be improved by allowing quicker scaling without blips. It would help if it were more dynamic and required less planning. You can't just scale back performance and storage as needed. Adding flexible scaling capabilities would enhance performance, making it greener and more efficient. Additionally, addressing the reliability issue where the database might crash during sudden performance peaks would be beneficial. Azure PostgreSQL's monitoring and management tools are constantly improving, but costs can be challenging. Azure Monitor provides the default metrics, but if you want all the metrics, you need to enable all logging, which will have more cloud costs than the database itself.