PostgreSQL Reviews

PostgreSQL is an open source database, so there is no associated licensing cost for the software and we always have a new version easily available. It runs on all major operating systems, although I have always used it on UNIX platforms.

It also supports storage of binary large objects, including pictures, sounds, or video. It is highly scalable, both in the sheer quantity of data it can manage and in the number of concurrent users it can accommodate.

PostgreSQL runs stored procedures in a lot of programming languages (Java, Perl, C/C++, etc.). It includes many built-in functions from basic math and string operations to cryptography and Oracle compatibility. Triggers and stored procedures can be written in C and loaded into the database as a library. PostgreSQL uses a multiple row data storage strategy called MVCC to make PostgreSQL extremely responsive in high volume environments. Allow hot backups.

I have worked at the Ministry of Economy in the IT area, for more than 20 years ago. Since then, the main developments have always used PostgreSQL for their robustness, reliability, stability, and conformity with the standard SQL.

I have noticed that it consumes a lot of resources. I would improve this aspect.

We had no issues. PostgreSQL statistically does not suffer falls, it simply works.

We had no issues. We had to modify some configurations but the impact was almost transparent.

All the obstacles that we encounter are solved with information obtained on websites. PostgreSQL has a community of thousands of users and professionals who contribute their experience, so I always have found a solution for all my issues.

I have used other solutions for over 20 years and the problem of licensing has been our biggest drawback because of the costs and dependence we require from the provider.

It is extremely simple. In addition, we have several databases in production so we always start with a configuration model already tested and reliable.

I recommend PostgreSQL without doubt because my experience of almost 20 years with this product has shown me that PostgreSQL has certain features that make it highly reliable: high scalability, robustness, available for multiple platforms, extensible with little effort and without additional cost, designed for high volume environments, easy to manage and extensive online support.

I recommend everyone to get into the PostgreSQL world, with no licensing costs. PostgreSQL uses a flexible and business-friendly license because it does not restrict the use of PostgreSQL with commercial and proprietary applications. Those who choose PostgreSQL forget the dependency on a provider, the price of the licenses and the changes in the license conditions.

We got carried away by the experience of a team member with experience in PostgreSQL and first we used the tool in applications of low concurrency of users but with storage of files pdf, doc and xls in the tables. We were surprised by the results. This is how we trust in PostgreSQL and we demand more and more. We always get good results. Sometimes we have had to migrate to a new version of PostgreSQL, but have done so without any problem(s).

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.

This solution is very good for getting data. It is very useful for reporting purposes. We also use one of the tools of IBM Cognos for reporting purposes.

For small-scale setups, the solution is stable.

The solution is open-source and free to use.

Currently, we are working with Postgre's economy, and we are not able to implement real-time solutions with our existing architecture. There's a general lack of real-time data from Postgre.

The solution isn't as stable for larger data sets. 

The scalability is limited.

We'd like the solution to be faster. 

I've been working with Postgre for the last two years. However, the organization that I was working with from the beginning has been using this. This was open-source and they've been working with it since 2017.

The product is stable only for working on relatively small data. It's not ideal for large amounts of data. Our business has grown rapidly. We have more customers and our data has grown very rapidly. We need to manage performance and tuning and may need a grander product. The performance could be better.

We're struggling with scalability. It's one of the issues we're facing right now.

This is hosted by this AWS. We generally raise tickets to them whenever we're in need of assistance.

For example, if we're doing any replication or any of that thing, we just raise tickets, and it gets resolved through them.

The support has been pretty good.

I was not involved in the actual deployment of the solution and therefore cannot speak to how difficult or simple the process was.

Currently, I've been given the role to do some research and switch to a different database.

The solution is open-source. We don't need to have a license in order to use it. 

We're currently looking for a more modern solution to replace Postgre. I'm aware of AWS Redshift, Query, and Nextly. These are major players in the market.

We are just a customer of Postgre.

Since the data volume has increased rapidly, we are concerned Postgre won't be suitable for our long-term requirements. We're currently looking for an all-in-one option.

I'd advise users that are not looking for speed or do not have huge amounts of data to try this solution. 

I'd rate the solution at an eight out of ten.

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.

The database for the accounting systems is our primary use case for this solution. Business software is 80% of my use case in the accounting software. It's a good tool for planning. I work with financial data and the data mining aspect is very important, as I need to access the data easily. The data is the most important thing. Sometimes the software developers forget this part because they just want to save the data on the database, but they don't know how to manipulate the data. The performance of the solution is dependant on how easily and quickly you can obtain access to the data.

I can use Unity Kinematic. It's not easy but you can create a multi-tenant database in Postgres and I think it's a must-have in software development. With the database, you can provide a multi-component at the same service with the same performance, scalability, or all those things. 

PostgreSQL is limited to 32 TB in maximum table size for version 9.6 and earlier. This can be problematic for large databases. We currently don't have the multi-tenant feature and we require that with the contract integrated reassurance. To create have one tenant or more tenants, I need to implement or develop a software solution to connect with the multi-tenant, and to connect each tenant. PostgreSQL is not great for software developers, but it is adequate. For developers, databases such as Firebase and MongoDB technology are better. With PostgreSQL, all you need the database for is to save your data. This function on its own is not enough. The database and applications can become very slow. To debug you need to make the database query display information on your device. Some developers are not experienced in developing databases. This is especially difficult for junior software developers, and they often need more experience to be able to deal with that aspect.

We have been using Postgres for about 10 years. 

It is a stable database.

Because PostgreSQL is limited in regards to the amount of data it can hold in a single table, you often think it might be better to change the technology. Other than that, it is a good solution for business.

Sometimes it is not simple to resolve issues, but the PostgreSQL community sometimes helps to find answers to questions.

I think it is difficult to setup. I amended my ID and Oracle advised me to change it, for it to work.

If you want one tenant, you can use MySQL. If you want a multi-tenant, I think Postgres is better. SQL on PostgreSQL is linked to Oracle. Oracle and Postgres is the same thing, the same language. You will not have a big change for the software developers to migrate from Oracle to Postgres. 

I would rate PostgreSQL 8 out of 10. 

One use case is that we installed it and built it for a customer so that he has access to the database, and he can create whatever he would like to create on it. 

We have deployed it on-premises and in the cloud.

It is easy to install and easy to manage. There is no license on it, so it is free. 

There is high compatibility with Oracle, and there are many tools for the migration of data from Oracle to Postgre. 

It still needs to be more mature and have some backup feature. We are normally dealing with Oracle's data, and we have very strong online tools to back up the data and do other things. PostgreSQL still needs to do more in this area as well as in the high availability area. There are many external tools that you can use for PostgreSQL's high availability, but there is no embedded tool within PostgreSQL for high availability.

It could have a feature similar to Oracle for working on a distributed system. It can have some scripts to improve the monitoring and some tools to do performance analysis. We have a workaround for most of such requirements except for the support for a distributed system, which is very difficult to have. This area should be included in the core of the database itself. 

I have been using this solution for almost one year.

I didn't have any issues, but I think Oracle is more stable.

I didn't have experience with that because we didn't make any changes since we built it. All I have is one server, and I can only have one standby, nothing more. 

We didn't contact them. We didn't face any serious issues that required support.

I am also using Oracle Database. The main difference is the scalability. PostgreSQL could be used for small to medium databases but not for a huge production database. I still prefer to have Oracle Database.

The initial setup was straightforward. It did not take too long. It took maybe one hour to do the installation.

It is free. There is no license on it.

Go ahead and implement it. It is a nice product, but keep a backup and try to use it for small to medium projects or companies. Some of the customers are demanding PostgreSQL nowadays, so we will keep on implementing it.

I would rate PostgreSQL an eight out of ten.

The product is easy to use and works fast for relational databases.

There could be a plugin to distribute the data on servers for the product.

We have been using PostgreSQL for one month.

I rate the platform's stability an eight out of ten. It could be better.

The product's scalability for large databases needs improvement. Like Oracle, there could be an option or solution to manage if the data exceeds.

I have used MySQL.

The initial setup process is easy. It takes about ten minutes to compete.

It is an open-source platform.

If you need a relational database, the product is a good fit. However, it is complicated to scale for large data. I rate PostgreSQL a nine out of ten.

We deploy our databases in either a local cloud or AWS. For the locally deployed database, we have our own private cloud consisting of a couple of different data centers that we partner with. For everything else, we use Oracle or Microsoft SQL. On the Microsoft SQL side, that's not usually software as a service. It's generally done as a local installation on a virtual machine. If we're doing a deployment on an AWS environment, we use the AWS Postgres database. It's slightly different than doing the installation yourself. So if you're doing the PostgreSQL installation on a Linux environment, that's usually when we're using that directly from postgresql.org. 

It's an open-source database, so we can see the code used for that database. Also, we use it because it's lightweight, easy to deploy, and scalable for particular projects, especially if we're dealing with something that requires a Docker deployment.

I'd like to see better memory management. I think that that's one of the few areas that Postgres does not handle as well as MySQL does or did. 

I've used PostgreSQL off and on for different projects for probably about 20 years now.

Postgres' stability is wholly dependent on the skill and knowledge of the administrator who deployed it. Postgres is rock solid when deployed according to best practices as documented by the PostgreSQL community. When it's installed correctly, PostgreSQL is an enterprise-grade solution. It's reliable but requires more familiarity than you would necessarily need with a database like Oracle or Microsoft SQL out of the box.

The biggest shortcoming of Postgres and most open-source applications is support and documentation. There's usually a decent amount of technical documentation. That would be for someone that works exclusively within the database. But it would be helpful to have more documentation at the DevOps level so developers have a better idea of maintaining the database's performance without necessarily requiring a developer who specializes in that database. A lot of DevOps people are much more interested in writing their code for the databases to work. And sometimes, they end up devoting more time to database tuning than is necessary for an application developer. So documentation in that area would probably be best.

So back in late August, the developers released PostgreSQL 14, the most feature-rich deployment to date. And they did a reasonably decent write-up about the new and unique features. What I found most interesting is that you can use a straight-up Windows installer for the PostgreSQL database. And it includes all the components of the stack you need, so you don't necessarily need to know how to install its different parts. For example, suppose you're going to install it for Solaris, BSD, or Linux. So when you're installing in those three environments, it's usually packaged and requires secondary packages. And some of these packages are version dependent, so it can get complicated pretty quickly. If you are curious about how PostgreSQL databases run, I suggest you try it out on Windows first.

We use PostgreSQL alongside Microsoft and Oracle solutions. Postgre is suitable for scaling with specific projects. But while it scales very well, Postgre doesn't have the same recovery features as some larger-scale databases. For example, you can run Oracle Databases in a couple of different ways for easy recoverability should the primary database fail. First, you've got a rack for redundancy and load distribution. Second, Oracle has a feature called Data Guard that replicates the database in case it goes down. Data Guard allows you to run a completely different copy of the database that will take our main exports and keep it up to date. So if your primary database has a software or hardware failure, you can bring up the secondary database and re-task your applications to use that database. It's not as simple to do this with Postgres. 

I rate PostgreSQL eight out of 10.