EDB Postgres Advanced Server Review

Provides enhanced functionality but the technology is aging


What is our primary use case?

We have around 170 data centers around the world. We deploy our projects based on the use case and requirements and the projects can vary. Most of those deployments for Postgres are for engineering purposes.

How has it helped my organization?

It gives us a solid, less expensive alternative to deploying with Oracle if it is approved and certified for use with the applications it will be running.

What is most valuable?

Cost/benefit wise Postgres is a great solution. It's a very fast database and — in terms of licensing costs — it also provides a significant TCO reduction compared to Oracle. In terms of specific features, deploying Patroni cluster with PostgreSQL we can achieve full HA capability for mission critical applications.

What needs improvement?

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.

For how long have I used the solution?

We have been using this solution for about 10 years.

What do I think about the stability of the solution?

Postgres itself is very stable. I can't really say that anything about the stability of the producT is bad. It's our first choice to use after Oracle. If we can avoid to set up Oracle to reduce some costs, we use Postgres. It depends on the application side. I work in the IT department but the company is not an IT company. We approach solutions from a technological perspective. Most of the time we have to deal with the client, the market, the vendors and deploy their applications on different databases. So we look to use Postgres if it's possible. But if the vendor doesn't certify the application on Postgres we need to deploy on a database that is certified for the application and we cannot use it as a solution.

What do I think about the scalability of the solution?

As far as I know, the only way to scale Postgres is to set up a Patroni cluster. I'm not experienced in adding nodes. That might potentially be another option that can be done without any kind of issue. 

I can say that we have some 2,000 people using the Postgres solution and if we had to scale, I am sure we can find a way to do it.

Right now our architecture is scaled to 12 nodes. Or it is a six-plus-six node setup. The bandwidth is run one-at-a-time and is not maintained at a maximum level so we maintain performance.

How are customer service and technical support?

I do not have any direct contact with technical support.

How was the initial setup?

The setup for the product is very easy. I didn't run the setup myself as we have a technology department that does that. I never heard through them that they had any problems.

What about the implementation team?

We have around 170 data centers around the world and we do the installations.

What's my experience with pricing, setup cost, and licensing?

The price difference compared to more expensive solutions like Oracle is significant. It is a solid, less expensive choice.

Which other solutions did I evaluate?

We are still a big Oracle user with maybe 500 Oracle servers. Postgres was an option we selected as another opportunity for deployment because, money-wise, the savings on licensing made it a good choice. It's a very reliable database. The licenses are very cheap compared with Oracle, but then again, the problem is always the same. If the application is supported by the database, we can consider using Postgres as a solution. Otherwise, we can't choose it for deployment.

What other advice do I have?

Even with all the improvements that could be made to the model and the functionality, I would give Postgres a seven out of ten. Obviously, it does not score higher because the technology is aging a little and it is not keeping up with other products.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Add a Comment
Guest
Sign Up with Email