PostgreSQL Reviews

We use it in new team architectures, microservices architectures, and databases that are relatively small.

We also use it for table data, public web pages, some server applications that require data persistence, and some backend modules.

It's a useful solution, that can be widely used.

It is easy to use.

PostgreSQL has a large community.

The performance is good.

We don't have any use cases where we would use it in a large application as we do with Oracle. This is one limitation of this solution. We are unsure when it comes to deploying a large 24/7 application. 

It is possible that in the newer version this has been addressed, but I would like the deployment in microservices architecture could be improved.

I have been using PostgreSQL for five years.

We use several different versions. It is determined by the application. For server applications, we use version 9, which is an older version, and for others, we use the most recent version.

PostgreSQL is a stable solution.

This solution is used by 10 people in our company.

It is supported by a third-party company.

I have never contacted technical support.

I am also using Oracle.

I have no experience with the deployment of this solution.

The licensing model is good.

I would recommend this solution to others who are considering using it.

I would rate PostgreSQL a nine out of ten.

We often use PostgreSQL for operations monitoring because we are a manufacturing company.

We often find the solution's datetime datatype challenging.

I have been using PostgreSQL for four years and five months.

PostgreSQL is a stable solution, and we haven’t faced any performance issues.

We faced no difficulty in installing PostgreSQL.

It took us five minutes to deploy the solution.

Overall, I rate PostgreSQL an eight out of ten.

We are using it as a database to store information.

Postgres SQL is quite a good database.

The performance is good.

I have noticed that user and access management should be improved. Connection pooling should be improved. We rely on connection pooling.

Monitoring is incompatible. It is open source. To advance, you must access the internet and download and test various other tools, or develop your own tools. With Microsoft server, it is one single platform that provides you with everything, but with Postgre you have to install or check different tools to integrate with it. That's the annoyance, but it's still the way open source technology works.

I would like to see better management in PostgreSQL.

PostgreSQL is easy to scale.

We have a medium-sized company.

We don't have technical support. It is community-based. We get assistance through Github.

We have been working with Microsoft SQL.

The main difference between SQL and Postgre is that Postgre is open source. It's completely free.

It's very simple to set up.

Postgre is open source. It is almost completely free.

The community version of Postgre is basically free.

We are utilizing the database's active native security features. As a result, we currently have no need for any external security tools. We had, but we worked around it.

The advice would be to go with a managed Postgre. If you're going to install Postgre in the cloud, for example, it's better to go with a managed Postgre rather than handling everything on our own.

I would rate PostgreSQL a nine out of ten.

PostgreSQL has excellent support for many programming languages. We've been able to integrate it with Java, PHP, Perl and .NET without any issues. 

Replication is also working pretty good in a master to read only replica setup in AWS. 

We've been able to cut costs on databases over our previous solution with Microsoft SQL Server and migrate many applications into Amazon web services. Performance has been decent. 

By far the biggest limitations are in replication support. A native master to master replication option would make things much easier as we're in need of an easier method to load balance traffic with Spring Data.  

PostgreSQL is slower than MySQL with insert performance. While using COPY can make an application fast, we often use ORMs which cannot benefit from this. 

9.4 seemed to have some regressions with the query planner and multi table joins are slower than in previous versions. 

I've been using PostgreSQL for 5 years.

Finding the right configuration to balance performance and connections was a little challenging in our setup. 

We've encountered some CPU bound scalability issues with multi table joins (3-4) and the query planner seems to ignore indexes at times. 

Initially applications at my current employer used Microsoft SQL Server. The cost for licensing/maintaining windows systems was more than we liked. PostgreSQL has offered similar performance for our workloads with lower cost. 

We use it for inventory control.

We are able to use it on many servers and incur no cost impact, whereas Oracle charges you by the number of cores that are on each individual server, whether you use those cores or not.

The main value is that it is open source, which means it is free. Our organization has the initiative to go to open source to cut down on cost. Oracle costs us $6 million a year right now, which is killing us, and Postgres costs nothing. So, there is a big push to go to Postgres.

It is a great product, and it just works. 

They need to have a better graphical interface. There is a tool called pgAdmin 4 that they use, which is free. It is written in Java, and it is slow. They need to have a better product that is similar to Toad for Oracle, but, of course, it is hard to get something that's really great and free. Other than that, it is great.

I have been using this solution for three years.

It is better than Oracle. It is a great product.

It scales horizontally, so it is great. You can do whatever you want with it. We probably have 10,000 users. In terms of their role, they buy products, put them in the inventory, and distribute them.

It is being used quite heavily. The idea is to get rid of Oracle and replace Oracle with Postgres.

It doesn't have any support because it is open source. They provide you with the documentation that's free, and you get everything except help. You're on your own, which is okay. I and one other person came up to speed on this, and we're basically the subject matter experts (SMEs).

EnterpriseDB (EDB) is a company that provides technical support, but we decided not to do that.

We used Oracle. We're currently in the process of migrating from Oracle to Postgres, and we're doing it because of cost.

Postgres is a superior product, and it is free. Oracle's support is really terrible, so you're not really getting any support from Oracle.

It was very straightforward and easy. It is very well documented.

We can deploy a server in about three or four hours. We use a primary and a standby server, so we have two servers in the cluster.

My partner and I read the books and then just did it. I am on the development side. They get the new products in, and I and this other person evaluate them and learn them. We probably have three people in operations who are handling Postgres on the production side.

It is free. In terms of operating costs, it basically needs the same platform on which Oracle runs.

We evaluated EnterpriseDB (EDB) Postgres, which is a paid product, whereas Postgres is open source. We decided that it was better to go with a free product.

I would absolutely recommend this solution if you're concerned about cost. It seems easy and straightforward.

I would rate it a 10 out of 10. It is really great. It works amazingly well.

Twice now, I have been involved in the decision by a company to migrate away from MS SQL Server to Postgres. The first time, it was simply a matter of scalability. Once you approach 10 TB of data, managing it in MSSQL becomes problematic. You reach limits on performance, backup/recovery and general maintainability. The second company that I assisted in performing this migration chose Postgres due to the TCO as well as the ability to scale the databases horizontally.

The feature that I find most useful (and in fact critical) is the extensibility of Postgres. We installed the extensions that were important to us and ignored anything that wasn’t useful. This allows us to maintain a highly customized configuration that is still able to be supported and maintained by third-party vendors.

One of the key ways that Postgres has improved the functioning of our organization is by freeing up financial resources that can then be applied to upgrading existing infrastructure. A side benefit, of course, is that by bringing in another platform, we have given current staff the ability to grow their skill set and experiment with a new, feature-rich environment. This improves employee satisfaction and makes our CFO happy at the same time.

I would really like to see a more mainstream approach to support what we see as critical extensions. One example is the FDW (foreign data wrapper) for MSSQL. This extension hasn’t been updated in several releases and would benefit from an overhaul. In general, the Postgres community is not as enthusiastic about supporting integration with Windows products (MSSQL, AD, etc.) as they are about other products like Oracle, GIS and full-text searching.

I have been involved in various aspects of Postgres for approximately two years. This includes both single-node installations as well as multi-node clusters using PostgresXL.

The only issue I have ever come up against is internal support. Implementing Linux and Postgres in an environment where only Microsoft has lived has been challenging at times. Administering Postgres on Ubuntu (or any other variant) takes a far different skill set than supporting SQL Server on Windows.

As far as scalability goes, I have yet to identify the limits of Postgres. We will be looking at the newer multi-node options from 2nd Quadrant later this year.

Like any open source product, your mileage may vary. There are several VERY good third-party options for technical support. That being said, this product is not for the faint of heart or the technically unsophisticated shop.

See my answer above. We evaluated both open-source as well as proprietary solutions. Of the open-source solutions we examined, Postgres has the best track record for innovation and enhancements. While the user base is smaller than some of the more established solutions, the fact that it has been able to avoid being “acquired” by a major player is, in my opinion, a plus.

Postgres will work straight out of the box on most platforms. However like all of the database vendors in the Unix space, the ability to modify the configurations are extensive. The degree of complexity is less than Oracle or Sybase but certainly more complex than something like SQL Server. The most important thing to keep in mind is that you must understand how your operating system handles memory. The most complex part of the Postgres installation is, by far, security. I would recommend getting help before tackling the HBA configuration file.

Both times I have been involved in an initial Postgres implementation, we have handled it in-house. It isn’t too hard to implement but you do need some base tech skills including Unix. I would not recommend trying to implement it on a Windows server.

For us, the ROI was almost immediate. We saved several $100k in license costs alone. Overall, the manpower costs to support Postgres and Linux will depend on whether those skills already exist in your enterprise. If you plan to take a Postgres system live in production, I strongly encourage you to look into commercial support.

If you can, do it!

I have used it in the past for some web applications and back-end databases. In my current organization, we are using Microsoft SQL Server.

It is very useful for both structured and unstructured data. You can store unstructured and structured data in PostgreSQL. It is easy to use. You can easily manage things through PostgreSQL Admin.

It is cost-effective. Its on-premise version is free. It is agnostic of on-premise or cloud. You can install it on the cloud or on-premises. It is available with all clouds, and you can also install it on desktop or Windows Servers.

It would be good to have machine learning functionality in this solution, similar to Microsoft SQL Server and other solutions. Machine learning capability for a basic level or a common user would be useful.

It can also have good reporting capabilities.

I have been using this solution for a couple of years.

PostgreSQL has been in the market for a long time. It is quite stable.

It is scalable. In my past organization, its usage had increased a lot. I had implemented data management and many other things on PostgreSQL.

In terms of the number of users, we had hundreds of users who used this solution. For development, we had seven or eight developers. We also had technical support and application teams.

I have not interacted with the support of Postgres because when it is on the cloud, it is managed by the respective cloud provider's team.

We used to provide service to various clients, and we were also providing internal services. We used different solutions in parallel, such as Amazon Redshift, MySQL. MySQL is also free. I have also used Oracle and IBM Db2 in other organizations.

Its installation is simple and easy. If it is in the cloud, you have to go for a subscription. On a desktop, you can install it with normal Unix commands.

I have not done full server version installation myself. If we go for Azure Cloud, its API is available. It takes five minutes to get it up and running on the cloud version. For desktop deployment, you can complete your setup within half an hour. 

It is open-source. If you use it on-premise, it is free. It also has enterprise or commercial versions. If you go for the cloud version, there will be a cost, but it is lower than Oracle or Microsoft. 

I would definitely recommend this solution. It is a very good database to have. It is also very good as compared to other tools.

I would rate PostgreSQL a nine out of ten. 

I use PostgreSQL on-premises to store monitoring data collected by  Zabbix Server.

I wanted a database engine that could handle an ingress of a thousand real-time values per second, delete old items without affecting performance, and handle hundreds of user queries at all times.

The solution had to support high compression and time series data while maintaining data integrity and performance.

I wanted the database engine to be easy to tune, secure, and set up.

PostgreSQL matched those requirements and has regular updates and plenty of official and community support resources.

PostgreSQL greatly improved our monitoring solutions data storage, performance, compression, and processing. Our monitoring solutions run efficiently with little maintenance.

The availability, stability, and reliability of our monitoring solutions greatly improved because the database engine scales out well, is easy to tune, easy to upgrade and manage, and supports extensions and plugins for specific use cases. One such plugin is TimescaleDB and it has proved greatly beneficial for time-series data storage and automatic partitioning of the database.The upgrade of the database has been great too, from 12 to 13 to version 14.

The most valuable feature is support for the Timescale DB extension. We managed to reduce the storage space needed to 10% of the original size, without affecting data integrity, and we significantly improved the performance.

The database engine is easy to manage, the tuning is friendly, and the integration with supported extensions is friendly too.

The database engine is free and open-source, too. Since we did everything internally, it has greatly reduced the costs of setting up our systems.

It also supports diverse kinds of replication, which is crucial for a high availability environment that we plan to set in the near future.

PostgreSQL uses high memory compared to its counterparts when a highly demanding workload with many database connections is in use, especially one that makes many concurrent connections to the database. 

Like many other databases, the tuning is manual through a configuration file. It would be useful if the database engine could detect the specifications of the machine in which it is installed and so bring some levels of auto-tuning. 

PostgreSQL replication support isn't so straightforward for multi-sources and master replicas. It will be great if native support of those replication modes become available in the future.

I have been using PostgreSQL for more than four years.

Stability-wise, I have a great impression.

It can be easily scaled.

We haven't used the official support but judging from the available resources on the website and other outlets it seems their support is good.

Positive

I used other database management systems (MySQL and its variant MariaDB) for my NMS applications before moving to PostgreSQL. I had some optimization issues on MySQL and MariaDB and decided to switch to PostgreSQL, mainly for the TimescaleDB extension support provided on PostgreSQL and which my application natively support including automatic database partitioning and compression. TimescaleDB proved to be helpful since I mostly deal with time series data and the TimescaleDB hypertables improved my applications perfomance greatly.

The initial setup was straightforward, although it needed time to get everything well-tuned. 

I implemented in-house.

The ROI is 100%.

PostgreSQL is free and open-source, so if capable admins are available then the setup cost can be negligible. We use internal resources, so it was completely free for us. One can choose the available official support too.

I evaluated other options including MySQL and its variant MariaDB & Percona Server for MySQL, Oracle DB, and SQLite.

For anybody who is considering this solution, my advice is that it is better to do enough research on the specific database engine requirements.

I highly recommend PostgreSQL with TimescaleDB extension for time-series data.