PostgreSQL Reviews

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. 

The database is used for our customers' products. We also offer some products on our POC system, and our customer's POC systems post some data stored on PostgreSQL on the cloud. Our company's data doesn't store at PostgreSQL. We still have our system MS SQL and Oracle.

The solution is very easy to use. You don't have to be extremely knowledgeable or technical to take advantage of it.

The product is quite flexible. 

We find it to be one of the cheapest options on the market. It's not expensive to use. 

The pricing could be better.

We've used the solution for ten years at this point. It may even be longer.

The solution is quite stable. We haven't had any issues with it. We haven't experienced bugs or glitches. It's reliable.

The solution is scalable. We've made some upgrades on our system, and it was so easy to do for the actual upgrades. In terms of the database itself, we haven't really had any issues with it.

I don't have any experience with technical support. Other teams in our company end up handling that. I can't speak to their knowledgeability or responsiveness having never worked with them.

I don't recall us using a different product.

In terms of the initial setup, we generally use the cloud system. The cloud system is very easy to set up these days. If you choose some with pre-installment, you trigger the system, and it's pretty automatic. You don't need a lot of things configured. After that, after you start to use it, you can tune it as you like. We made some adjustments on the system - such as additional storage or additional RAM or other resources - and we were able to add those in very easily.

The production system we use for reporting is a read-only system. Due to this, if we use the production system for reporting or other kinds of big data, the system can be slow on the customer side. However, Postgres can still service all the tasks which we need.

We haven't needed too many people to handle deployment and maintenance. There's been around ten or so that have been on it.

The pricing is reasonable. Of course, our economy has been hurt a little due to COVID-19. The pandemic has affected a lot of us. It's been hard for the companies that sell services with a database cost. You really have to choose the lowest-priced options right now. Postgres offers a fair price on the market, currently. That said, it could be less expensive, especially right now.

We definitely plan to continue to use the solution in the future. It's been quite good for us.

That said, I'm not in the financial department and I don't know the exact cost of the solution.

We're just customers and end-users.

We generally use the last version, as we try to ensure all of our programs are the latest technology. Therefore, we generally use cloud platforms like Amazon or Microsoft, which is Azure. Whichever version is on the cloud, we generally use that version.

That said, some of it is on the cloud and some of it is on-premise. In Turkey, we have some legal requirements that require some data to be stored in our country. We have to store it locally. Therefore, we can't use the cloud completely.

I'd recommend the solution to other organizations.

I would rate the product at an eight out of ten.

The reliability, performance, and extensive list of features are what I think matter the most in a production environment.

I have never been in an environment where PostgreSQL was not used. It was always used alongside other RDBMS solutions, depending on the specific requirements of each project. In this way, we were always sure that we would get the best out of it.

There are still things missing compared to other RDBMS, for example monitoring is a little behind as there not that many solutions out there. An equivalent of Oracle's RAC and/or flashback logs would be nice to have. There are a lot of steps need to get it back on the right direction with the logical replication and the parallel sequential scans.

What I mean is that despite the fact that there are things missing (like monitoring solutions and/or flashback logs etc.). Lately, there have been some developments that seem promising and set Postgres to a proper path. Two of these developments are the logical replication and the parallel sequential scans, and compared to other RMDBs, some could say that these are long overdue but nevertheless, they are a great addition and will definitely improve the performance/scalability/replication-capabilities of postgres in the current version and in the versions to come.

I've used this solution in an enterprise environment for a little over seven years.

There were no issues with the deployment.

I have never had a problem that was directly caused by PostgreSQL itself. Usually what happens is that a lot of databases are mistreated in the sense that they are misconfigured, or not designed properly, and then blamed for the issues that are happening as a consequence. Apart from some minor bugs that have recently been fixed, I have never had such an issue.

It's been able to scale for our needs.

There is no real customer service. There are forums where the core-committers and other people are usually very willing to help. I have tried posting a couple of issues I have had and I got a lot of feedback that was really helpful.

The initial setup is very easy. However, if you want to go deeper and understand how things work and how you can tune the database under various circumstances, then you need to read a lot of books and gather more and more experience.

I have never tried implementing it with a vendor. I was always part of an in-house team and we never faced any issues that would make us need to use a vendor team.

I am working with other databases, and not exclusively with PostgreSQL. A lot of other RDBMS require you to pay large amounts of money so I would say that you need to carefully plan your projects according to your needs. If there are specific needs that cannot be met with open-source software I can understand this choice, but otherwise I would always place more trust in the open-source software and its community.

I have tried and worked on other solutions such as Oracle and MySQL. I would say that the combination of PostgreSQL's features, plus the reliability and performance it offers in combination with the fact that you don't pay for a license was the reason I chose it.

There are some features missing compared to other RDBMS. The community is always expanding and more and more people use PostgreSQL every day. There are many forums where you can get information from and there are many different ways to contribute.

For this question I will focus on our usage of PostgreSQL in the company. A great differentiator for this database, if compared with other providers, is its easy extensibility and the existence of data types that would fall in the category of NoSQL. In particular, HSTORE (key/value store) and JSON (documents). This feature makes it possible to combine the strengths of relational and non-relational artifacts. Specifically transactionality and indexing vs. hierarchical structures and flexibility.

The company I work for creates economic time series and forecasting’s based on monthly surveys with companies. Besides a set of general questions, different sectors of economic activity include questions specific to their sector. This means that we have different sets of answers depending on the survey. Instead of having a separate table for each set of answers, it would be nice to have a single survey data table including all answers from all surveys. The Oracle implementation that was implemented around 13 years ago stored the numerically encoded answers in a string. Along with that there were tables associated for each question in the string field name, the starting position, and the width of the answer code within the string. This system is very prone to errors and, more problematic; it is not flexible enough to respond to new requirements in a timely manner if our researcher wished to add questions in single months that are relevant for that specific period in the economic history of the country. All this was only possible at the cost of long implementation and testing times and eventually was never really done. With PostgreSQL we moved what used to be a string with fixed positions into an HSTORE (a key/value store) field. We have now named answers (the key) and their values. The HSTORE field is flexible, i.e. adding a single question in a single month simply means that only for that month there is a key pointing to the single question's answer.

v9.5, which we currently don't have in our productive systems, already has some key features that we would like to use. In particular, row level security, a feature allowing to restrict the visibility of rows based on a set of policies. A feature that is not available yet and I would welcome is more of a by-product. PostgreSQL offers very good documentation features, which we integrated in the technical documentation on our internal Wiki. Changes in the database are immediately available in the Wiki without the need of editing the Wiki page manually. It is possible, and we do it, to attach comments on objects and their components. These comments also appear then in the Wiki documentation. Unfortunately it is not possible, i.e. there is not an implementation yet, to attach comments to function parameters and return type. We make extensive use of functions as structured interface to applications. This feature would make our documentation more complete. We created a workaround for that, but still, it would be nice to have it built in the database.

I use the open source database management system PostgreSQL in different situations. In the company I work for we have version 9.3.5 running on Red Hat Enterprise Linux 4.4.7-4 64 bit. The choice of operating system and database version is not a thing we can influence much. Both are hosted by the central informatics services of the company and we have what we get. We can however decide which RDBMS to use and we chose PostgreSQL. For the web services that we implement for the association Swiss PostgreSQL Users Group we use version 9.4.6 on a Debian 4.9.2-10 (Jessie) server. Finally on my local development computer I use version 9.5.2 on LinuxMint 17.3 Rosa, a Debian like and Ubuntu based operating system.

In my company, PostgreSQL was introduced to replace Oracle slightly more than three years ago. Privately, I have been using PostgreSQL for about six to seven years.

There were no issues with the deployment.

We had no issues with the performance.

We had once a problem with a script that created a huge SQL statement with about 40,000 function calls. This led to a stack overflow. Thanks to the community mailing lists we were able to find quickly the origin of the problem and the correct approach to avoid it.

In this case that would map to the community support on mailing lists and IRC channels, and this type of service is very good. It is also possible, of course, to buy support from companies like Cybertec Schönig & Schönig GmbH (Austria), EDB in the US or 2ndQuadrant in Europe. I don't have direct experience with that, but I have often heard from colleagues that they are all excellent. This is quite simple to explain, because many of these companies' employees are active developers of the code base of PostgreSQL. They are also present on the many PostgreSQL mailing lists. If you are running a very critical system, and by that I mean a system, which failure could cause damages to people, I would strongly recommend that you hire at least two of these experts for a thorough audit.

We used Sentinel which was awesome but it did not provide metric views.

Installing a PostgreSQL cluster is straightforward. However, it is important to be aware of the architecture of the cluster, its configuration possibilities, and its authorization system. For the tuning of the configuration parameters there is no recipe, because it all depends on how the data looks like. Therefore it is necessary to understand what the individual parameters do and how they influence the overall performance. The correct usage of databases and schemas together with the authorization system, are important in order to build secure systems. It happens still too often on the world wide web that applications interacting with a database use roles with much too many privileges, creating security weaknesses. This however is not only a problem of PostgreSQL.

We did not implement the database software. What we implement is the design of the database and its interfaces toward third party systems and in-house applications. In the world of databases the person or team dealing with how data must be stored and accessed must possess complete knowledge about the processes being involved. It is not uncommon that web developer ask for accesses, which they are not entitled to and it is important to be able to offer an alternative. The most typical is a test database instance that web developers can use as playground.

PostgreSQL is a community product and has no owner other than the community itself. There are companies specialized in offering services and add-ons on top of PostgreSQL, but the database software itself is free, open source and licenced through a BSD and MIT derived licence of its own (https://wiki.postgresql.org/wiki/FAQ#What_is_the_license_of_PostgreSQL.3F).

Besides the simple fact of being an open product that can be used at virtually no cost, the quality of the code base is extremely good. The development process is transparent and the documentation is, with its 3000+ pages in the pdf format for version 9.5, exhaustive and complete. The community is very active and open to suggestions.

Stability, compound & functional indexing, MVCC, transactional DDL, GIS extensions, recursive queries, common table expressions, materialized views, procedural languages, triggers, and excellent documentation. PostgreSQL feels more like a mature, feature-rich, performant data platform than a simple datastore (I'm looking at you MySQL & Mongo).

Full ACID compliance for all transactions (including those with DDL changes) is supremely helpful when making modifications to the schema. The query planner and indexing functionality is second to none, making it one of the fastest database platforms available.

I would like to see the ability to reorder columns on a relation, as well as change the base SQL query that generates a materialized view without having to drop the view, provided the view's structure is unchanged.

I've been using it for over 12 years now.

Replication has been very easy to set up in recent versions. That said, there is a learning curve when it comes to server configuration.

We had no issues with the performance.

PostgreSQL does an excellent job of scaling.

There are companies that offer professional support. I personally have found the IRC channel to be an extremely effective channel of support, as many users and core contributors to Postgres often hang out there.

I've also used MySQL and MongoDB, but neither of those technologies provide any competitive advantage over PostgreSQL in any respect that comes to mind.

The initial setup was fairly straightforward. That said, configuring the server past defaults can be rather complex. Properly tuning the server requires a fair amount of knowledge concerning the architecture of PostgreSQL itself.

In-house. That said, it's very easy to spin up an instance using Amazon Web Service's RDS product.

PostgreSQL is completely free and fully open-source.

PostgreSQL is the world's most advanced and performant SQL database available. It essentially beats out MySQL, Oracle, SQL Server, and often MongoDB on virtually every use case.

JSON support, especially the new JSONB data type is valuable . We used to have a mix of PostgreSQL and MongoDB to solve some of the complex problem around data schemas, now, we rely solely on PostgreSQL as our main datastore. Same flexibility with rock solid performance.

PostgreSQL has been a key component of our business, it is a rock solid product with years of expertise behind it, it is more cost-effective than Oracle and allows us to focus on innovation rather than licensing costs.

JSON support although great, it still has some gotchas, querying and manipulating JSON will be one of the topics I'd like to see some improvement, still feels not natural to work with it.

I've been using it for around four years.

There have been no issues with the deployment.

We haven't had any issues with the stability.

We haven´t hit the point yet when scalability is a problem, but it would be nice if horizontal scalability comes out of the box

So far the community has been great with us, every time we have a question or not sure what is the best way to tackle a problem, we have encountered someone that is able to share his knowledge with us.

It was pretty straightforward, initially our setup was not complex on purpose, we were looking for a simple yet reliable setup, that allows us to gain expertise before moving to a more complex one.

All in-house. My advice is to try to keep things simple, it is harder to learn from complex setups where the setup itself is a problem too, work on complexity once you feel comfortable with the expertise you have gained.

In our case, our ROI is very high, we do not pay for licensing, we use the community version of PostgreSQL and sometimes use companies that provide a hosted PostgreSQL.

We evaluated Oracle, MongoDB and CouchBase. Although those seem to be different products, they have some common features that worked for us, we decided to go with PostgreSQL because of its reliability and proven track record.

PostgreSQL is a great product, very mature and is evolving into other areas beyond SQL, in this times of connected devices and big data analytics, PostgreSQL can still be considered one of the key components and works very well with others. Being reliable is still one of the best ways to get a good ROI.

We use the solution to conduct surveys and consider this approach to be one which is cheaper for us. 

The solution is quite stable. This said, it's more prestigious to use MySQL, although we haven't made comparisons for safety and reliability.

The performance is too low, although we haven't tested for this. 

The interface climate could be better. There are many third party ones that we can use so it would be nice to see more support with the database diagrams.

We've been using PostgreSQL for certain small projects for the past three years.

The solution is quite stable for our use. 

We haven't tested scalability.

I cannot say for sure if we have plans to increase usage, as we have yet to run a test. 

While we do benefit from technical support, this is not something that we have required. 

The initial setup wasn't difficult. I'd say it was quite straightforward.

The installation took less than an hour. 

The need for our customers to pay for licences is contingent on their projects and budgets. It varies. 

We are not consultants to PotrgresSQL. We are usually consulted when it comes to using Microsoft MySQL Server, since we consider it to be quite robust and to have all the necessary support from Microsoft.

Fewer than 10 percent of our customers make use of PostgresSQL.

I would recommend the solution to others when when there is a desire to have projects and cost is a concern.

I would rate PostgresSQL as an eight out of ten, although this owes itself to personal preference and not to low performance. 

Currently, I'm doing a lot of source applications with Ruby on Rails, React, and mobile applications. PostgreSQL is my preferred database over MySQL. It's open-source and licenses are free, so it is excellent. The SQL queries are almost the same as MySQL.

Clustering is the number one feature. It is also open-source so it is free. It can also be clustered, to allow fault tolerance. MySQL has to be licensed, but PostgreSQL does all the same things. I have deployed both. You benefit from the way you use it. 

It could be improved by using parallelization. We want distributed computing. Some databases handle huge volumes of data better, such as the NoSQL database, MongoDB which can handle 100 000, or a million people using the same data search. PostgreSQL is going to take longer to do this, but it is more structured, and unlike MongoDB data is less likely to be duplicated. Large volumes of data can be handled better in PostgreSQL if the queries are written well.

I have been using PostgreSQL for about 2 years. I used to use version 9, about two years ago but right now I'm using version 10 or 12. I know how to create database functions. I know how to create relationships between data like primary keys and foreign keys etc.

I think PostgreSQL is more stable than MySQL.

As an RDBMS, a relational database management system, it scales well.

I have mainly used the Stack Overflow site for support, which is not technical support in particular. I have never been in a situation whereby I'm stuck and I have to go and ask PostgreSQL support.

The difficulty of the initial setup depends on the application you are deploying the code to. It can be integrated with Docker to enable automation of this process. I put PostgreSQL in a Docker container and then I just collect it. It just works wherever I deploy it. It takes less than three minutes. I use a continuous integration process. The Docker orchestration engine such as Kubernetes or Docker Swarm can be used to integrate with it. I store the code in GitHub or GitLab and your code is always there. Depending on the technology you're using, some things change in your configuration.

I have deployed them to Oracle recently. I've also deployed it in the cloud. There's really nothing special about the cloud, as long as I use the PostgreSQL machine I can deploy it anywhere. I want to deploy it on the Google cloud platform, and Amazon Web Services as these are well known virtual machines.

When it comes to pros, I would put MySQL and PostgreSQL in the same class. let's say I'm trying to write to the database and then the power went off. It will still keep the data integral. I don't have duplicated data, and data integrity is intact. With NoSQL databases I have to duplicate queries in case something like this happens I don't know whether my data is going to be integral in cases like a failure situation. PostgreSQL has the rollback function which remains integral. I cannot build a search engine using PostgreSQL, because that would be a very expensive hit on resources. Alternatively, with the ElasticSearch utility, and the use of load balancing, it is very easy to use. Elasticsearch returns substantial results and works in the background. I cannot do that with MySQL or PostgreSQL databases as that's actually a very expensive use of resources.

My advice would be to use PostgreSQL instead of MySQL because of licensing issues. Another reason is that Oracle may remove MySQL soon or add substantial costs to using it It may even turn into something like MariaDB, and then you would need to know if MariaDB and MySQL work the same? PostgreSQL really works well. There are a lot of other databases around right now, but PostgreSQL is the most popular. It is not like a hammer and a nail situation whereby it is the only thing you have to use. If you need a relational database management system, go for PostgreSQL instead of MariaDB or MySQL, then use it side to side. Can also consider other engines out there, like other NoSQL engines, perhaps. 

I would give it an 8 out of 10. PostgreSQL is not suitable for all types of applications, hence why I gave it an 8 instead of a 10.