An area for improvement in EDB Postgres Advanced Server is JSONB querying. That feature should be more accessible because currently, you can mix structured and unstructured data, which means you can store the regular data you hold in your RDBMS and also store data in MongoDB. However, there's more room to improve JSONB support in querying the database and indexing to make it even easier.

My company does a lot of JSON data, and it would be nice to have a single database that can support both the JSON data and irregular roles and columns that my team manages. It would be nice to have even stronger JSONB support from EDB Postgres Advanced Server.

I have faced performance issues in the community edition. 

• Lighter integration model for containerized deployment.

Effectively, there still remain some issues with a containerized deployment, so we have opted for a non-containerized deployment. This makes pack distribution a little more time-consuming.

Because of the way Postres g9 / PostgreSQL is using their file system, I think it is not as efficient as it could be. They should start deploying a more effective file system structure to improve efficiency. Let's say we consider Postgres as the database for a solution and the rich machine contains the database and very, very useful solid-state disks to improve the performance and efficiency. That is the hardware is very good and very fast. I think that one of the most effective enhancements at that point is related to a file system rather than just the hardware. The structure of the Postgres file systems they have at the moment in the IT scenario is not very good in comparison to the ASM model from Oracle. Oracle deploys its own file system in order to be more effective. So, I do believe that one of the most important improvements that could be made to Postgres would be to take a step into the future. There are newer database models like MongoDB, NoSQL databases, some people are running on Hadoop. These are newer models and structures. Postgres could benefit from an enhanced file system dedicated to high performance. The next steps that Postgres Azure should just be to improve — to grow up — is to consolidate and enhance the file system. 

The memory management is another place where Postgres can improve. The shell buffer and the effective cache size are not very useful compared with the Oracle SGA. Better efficiency there will also enhance performance.

There are a few things to consider about Postgres monitoring. There are not many queries that can be run to collect information about what is happening in the databases from a file management perspective. They could use more substantial monitoring to help administrative efforts.

There is a group of things that can be improved in this Postgres model. For example the quota on the tablespace, the logging, the query hints, ETC. There are a lot of ways to improve and some are more important.

It would be most important to address the main things first. That would be the file system performance and monitoring. The reason monitoring is important is that sometimes you have don't have a clear idea of what is happening in the database. You can incorrectly blame the hardware. Or you can start blaming the virtual infrastructure. You can blame the storage Because the monitoring is not robust you don't have a clearer picture of what is happening on the database side. There are no statistics for the I/O, no reports for the CPU, there is no information about how the bottlenecks are managed. There should be tracing for the queries to understand what the problems are or if there are slow queries. From a management perspective, these are the most important things that could be improved. Postgres performance is suffering and the product model is not doing enough to keep current.

The product comes in two forms. One is the full enterprise version which comes with some type of product support. This is something you have to pay additional for but the cost is not very much. The other version of the product is a completely free database product, but it only comes with community support. The full product with support is not very expensive because this is an open-source product developed by the community.  For a transaction system that only needs to take many requests, it can be a good solution.  

What I would like to see to improve the product in the future are some changes to the security policies. What I mean more specifically is that if we compare Enterprise database products security features and Postgres security features, Postgres is maybe 5 years behind Enterprise database products in development. Enterprise database products has many more security features. For example, Enterprise database products can act as a firewall and it has a stronger buffer policy with many rules. Postgres does not have the capability to have very strong policy rules in place. It has only two or three basic rules for buffer policies and it has some stateless protocol and that is all. There are not enough options for stronger security.  

The lack of additional security features is really the thing that makes the product less useful.  

It suffers issues ranging from data corruption to failing to delete temporary files which then necessitate us having to perform server restarts.