EDB Postgres Advanced Server Reviews

Our primary use case for EDB Postgres Advanced Server was to study the code base behind it. We aimed to understand how it has been built, how the engine functions, the querying process, and what kinds of indices are available. This was part of our college projects where we explored its architecture and capabilities.

The number of indices available in Postgres is remarkable. Additionally, the way it forks each process into a child node, instead of executing in the same node, is quite different from most databases. These features can be especially useful in certain scenarios compared to MySQL or other SQL-based databases. Also, the ability to distribute the database across different machines is a significant advantage.

It was challenging to think of improvements for Postgres. We did not choose to extend or add new features to Postgres since it already meets our needs so well. There aren't specific new features we wish to add.

I have had experience with this product for the past year.

Postgres and MySQL are known for their stability and reliability, which is essential for a product server.

Although I do not have detailed insight into MySQL's scalability, I can affirm that Postgres scales effectively and performs exceptionally well among SQL databases.

Postgres has excellent documentation, which is very comprehensive and includes diagrammatic representations and visual aids. This makes learning and understanding the system much easier.

Positive

Setting up MySQL is slightly more straightforward than Postgres. I would rate the Postgres setup experience as seven and a half out of ten, compared to MySQL's setup, which I rate at nine out of ten.

I would highly recommend EDB Postgres Advanced Server to others. Most companies prefer Postgres or MySQL for a reason. The number of available options and the ability to distribute the database across different machines enhances its flexibility and features. 

I rate Postgres a nine out of ten overall.

I am a lecturer, and in universities, we use EDB Postgres Advanced Server to start with databases for practical purposes. I also assist with migrations, especially when clients want to migrate from Oracle to Postgres. So, while I am not a regular user, I am involved during migrations.

Since the initial cost of licensing is lower compared to Oracle, this is a benefit for our clients, particularly in the healthcare sector where I work with systems like the Visuraj Dashboard and appointment booking infrastructure. Maintenance is easier without needing third parties, thanks to EDB support.

The feature of vector database management for AI is quite interesting and impactful. Clients often compare it with other databases, such as ChromaDB. Additionally, the compatibility with Oracle is beneficial for middle—and lower-tier customers. EDB offers extensive support, low initial licensing costs, and comprehensive packages.

I would like to see improvements in the performance, especially in large-scale operations, as it currently cannot match Oracle's performance. Additionally, multi-tenancy architecture, microservices, and container-based architecture support are needed. Enhancements should be made in AI support and vector database features.

I have been involved with EDB Postgres Advanced Server in situations related to Oracle and Postgres migrations. It is not a continuous engagement, but I have supported the solution whenever needed.

Their technical support is quite good. Even for installation issues, support is readily available and competent.

Neutral

Installation is quite straightforward and easy, unlike Oracle. It's simple, just taking five minutes.

EDB Postgres Advanced Server offers both processor-based and user-based licensing options. The cost is reasonable, particularly for middle and lower-tier customers, but there are hiccups when dealing with large enterprises whose data exceeds one hundred terabytes.

For high-end, large enterprises, we recommend Oracle as it offers better performance.

I recommend EDB Postgres Advanced Server for middle—and lower-tier businesses. Its ease of installation makes it beneficial from a learning perspective. However, due to performance issues, Oracle remains the best choice for high-end enterprises.

I'd rate the solution seven out of ten.

The product is fast. I have used SQL Server before, and considering that Postgres is open source, its speed is remarkable. It's as fast as a proprietary server like SQL Server or Oracle. Additionally, it has many built-in features that make scripting easy.

It has good stability. I rate it an eight out of ten.

It is quite scalable. I rate it a nine out of ten.

The documentation is excellent. It covers everything you need to know, including how the features work and how to set everything up. Overall, it's very straightforward. 

Positive

The setup is straightforward, similar to a general setup. Someone with experience with other database software like Oracle or SQL Server won't need to learn anything new to set up Postgres. It's really easy to set up. Setting up any database can be challenging for a first-time user, but even someone with minimal experience can do it easily. 

I rate it an eight out of ten.

It's a cost-saving option if you're cost-conscious and want to avoid using SQL Server or Oracle, both of which I've used in the past three or four years and know can be expensive. It's cost-effective and gets the job done. From my experience, it's as fast as SQL Server, though not quite as fast as Oracle. I would choose this option if I had to choose between this and other providers.

It is free. You need to invest in the infrastructure to run the server, but it is free to set up anywhere.

Postgres is highly compatible with many software and programming languages. Its compatibility is excellent, covering nearly everything related to data engineering or migration.

They have some particular features that differ from Postgres, so there is an initial learning curve. Some features, like scripting, might vary from other database servers. There could be a slight learning curve for new users. It is the best open-source database server available.

It's good for machine learning or AI. The data processing needs are well-handled, and Postgres is relatively fast at retrieving, inserting, or modifying data. It will be helpful for these purposes.

Overall, I rate it around nine out of ten.

There are no specific use cases associated with the product. For my personal use, I installed EDB Postgres Advanced Server. When I was learning about databases, I installed EDB Postgres Advanced Server, specifically when I was playing around with queries. I am not working on any use cases with the tool.

The solution's most valuable feature is the pgAdmin part, which includes a dashboard showing the metrics associated with Postgres.

The product currently fails to offer a mobile application. In the future, I want the solution to offer a mobile application, especially since you can access the services via mobile phone with all the service providers like AWS and others. A mobile application provided by the product can help a user to see the status whenever needed.

I have been using EDB Postgres Advanced Server since 2016 or 2017.

Until and unless you pump in a lot of data, you cannot figure out the tool's stability. For my usage, I don't see any problems with the product's stability. Stability-wise, I rate the solution a seven out of ten. You will get to know about the stability of the product only when you use terabytes of data.

I cannot comment on the scalability of the product since it can only be determined once the amount of data used in the product increases.

As it is an open-source product, I did not get any technical support.

The product's deployment phase is easy.

The solution can be deployed in five to ten minutes.

The solution can be deployed by myself.

It is an open-source product.

The product is user-friendly.

I recommend the product to others.

I rate the solution a seven out of ten.

I have faced performance issues in the community edition. 

I have been working with the solution for four years. 

I rate EDB Postgres Advanced Server's stability an eight out of ten. 

We didn't get any support and used Google to search about issues. 

I have been working on the community edition. 

I rate EDB Postgres Advanced Server a nine out of ten. 

I use EDB Postgres Advanced Server for production workloads, but the solution also works well for development. Developers can have local versions, and it's also the same database you use in production.

I like that EDB Postgres Advanced Server scales well. It also gives you production features similar to what Oracle provides, but one valuable feature of the solution is multi-tenancy support.

Another valuable feature of EDB Postgres Advanced Server is that it supports JSONB.

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've been working with EDB Postgres Advanced Server for about three years.

I'm still working on it.

EDB Postgres Advanced Server is stable from version to version. My company didn't have any issues stability-wise, so I'd give it an eight.

EDB Postgres Advanced Server is very scalable, so it's an eight out of ten from a scalability point of view.

I haven't used EDB Postgres Advanced Server technical support.

The initial setup for EDB Postgres Advanced Server is straightforward, so I'd rate its setup as nine out of ten.

We implemented EDB Postgres Advanced Server primarily in-house, but sometimes, we use a third party.

For the cloud version, you have managed deployment, so it's easy to configure a container, and then it's done. Then there's native deployment, and developers have deployment on local machines, but either one is straightforward.

EDB Postgres Advanced Server has managed production, and the solution is out of the box, so it's very straightforward to deploy on Azure.

EDB Postgres Advanced Server is open source, so I don't pay for licensing.

I'm working with version 12 of the EDB Postgres Advanced Server.

One DevOps engineer is responsible for deploying and maintaining EDB Postgres Advanced Server.

About twenty developers work with the solution, and there's no plan currently to increase EDB Postgres Advanced Server usage.

My rating for the solution is nine out of ten.

My company doesn't have a partnership with EDB or with Oracle.

I'd tell new users of EDB Postgres Advanced Server, or anyone looking into implementing it, that it's a good solution that can scale well in terms of features. The solution has entry-level features that new users will be comfortable with and advanced features. When users need more advanced EDB Postgres Advanced Server features, they'll also be comfortable using advanced features.

In my experience, if you use something MySQL, you are always careful to use only the standard features. With EDB Postgres Advanced Server, you can use it in both development and production, which means you can use the full database features without worrying about compatibility. This is one pro of the solution as it's perfect for development, and it scales up for your production environment in terms of features, which is why my rating for EDB Postgres Advanced Server is high.

I am responsible for our database products. We use these solutions only on-premises because our government has placed restrictions on our type of organization. The EDB Postgress Advanced Server is something we use for simple database projects on linux.

This product has allowed us to reduce costs in some parts of our infrastructure without losing functionality.  

The part of the product that I find most valuable is using it only for small tables and databases that are not very complex. That is all we need it for although it is also valuable because of the low cost.  

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.  

I have been using the product for between two and three years. 

I think that the stability of the solution is very good. It is a very stable solution.  

For the purposes that we use the product for it has expected scalability. In our situation, we will not use this database, as far as I know, to work in a cluster. For what we use the system for, it just performs like a normal database. It is working on an x86 processor and we don't need it to do more. We do not have any problem with scalability. So we are satisfied with it.  

I am not exactly sure how many users are using this solution through our company and deployments. This solution is used to process some kinds of requests from our customers. I think we have used this solution for some of our internet banking. It is probably as many as one million users registered in the system and probably eight or ten TPS (transactions per second) for the database.  

We have just two DBAs from our side doing the maintenance of this solution.  

We have contacted technical support in the past, but it is mostly if we need some additional information about things we had not done before with the product previously. We ask the question, they give the answers and that is all.  

As far as I know, we have not had any serious issues with the product before which were the reason we contacted support. We just ask questions to get answers.  

The products we used most before Postgres were Enterprise database products. Of course, we are still using Enterprise database products, but we started using Postgres because it was cheaper and it could do what we needed it to in certain applications.  

The initial setup for Advanced Server is pretty easy. With our experienced DBAs, our deployment only takes about one day maximum.  

We do not use a vendor or other contractor. We deploy the product with our own team.  

The cost of the product is not really a question because the open-source product itself is free. The only cost in addition that we pay more for is the support payment because we have the enterprise usage and that is all.

The only advice I have for people considering implementing this Postgres Advanced Server solution is that it is cheap and can save money. It was a good lesson to learn that we could save money by working with Postgres. It reduces our costs when we are not implementing some bigger, more demanding software solutions.  

On a scale from one to ten where one is the worst and ten is the best, I would rate this product as an eight.  

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.

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.

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.

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.

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.

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.

I do not have any direct contact with technical support.

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.

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

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

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.

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.

As a replacement for Oracle RAC where there's need:

• More than four servers
• Dynamically deployable servers
• Split access between the transnational and reporting on the same data store.

• Major reduction in run cost, and a quantum leap in the flexibility of deployment models
• Elimination of replication of transaction from reporting systems
• Able to do rolling upgrades with zero production downtime.

• Variant server configuration: not requiring the same release on all.
• Effectively allowing us to be far more flexible from architecture to production, and the overall support model improves drastically.

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

This is an extremely robust, enterprise-grade solution that inherits all of the same reliability aspects of Ingress.

This is a very scalable environment both linear, horizontally and vertically.

Oracle RAC and Informix. The single reason for moving off Oracle was the hard limit of four servers in a RAC and the degradation of performance at that. Meaning Oracle really is not scalable across servers, but requires massive increase in individual server specs.

Oracle and Informix are more costly deployments and support models, from a pure licensing perspective.

This was a straightforward one-to-one activity, and both Oracle and Informix database were fully able to be completely comfortable within a day.

In-house team with advice from the vendor.

Recovery of investment was less than four months.

I believe this is a negotiation issue with any organization that is based on the size of footprint looked at. Hence our experience would not be applicable. But negotiate, negotiate, and negotiate.

Yes numerous options, include HANA, MongoDB, MySQL, and MS SQL. None of which were sufficiently scalable or at our size, cost effective.

The backup utility tools such as pg_restore and pg_dump are really convenient and efficient tools to handle backup and recovery.

We have deployed the database to support our tax management system. 

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

We have had no issues with the deployment.

The database has had stability issues.

The database has been able to support about three million taxpayers.

It's very easy and straightforward to deploy.

I would encourage any organization to adopt the solution as long as they are ready to invest in training and research. Supporting a PostgreSQL database requires highly skilled personnel.