PostgreSQL Reviews

In my experience, the data quality and extensibility are valuable.

I'm a data consultant that specializes in PostgreSQL. The combination of it's open community, open source approach and it's unique features make it the perfect platform for solving today's sophisticated data challenges.

Extensibility could be even better as there are still too many things that require programming in C to add to the database. There could also be better object-oriented support. The table inheritance feature is critical to some of my work, and I wish a similar concept existed for other objects.

I've used this solution for 20 years.

There were no issues with the deployment.

I've run systems that averaged 700-800TPS (over 24 hours), with peaks approaching 10,000TPS. That was on a 4TB database.

Postgres will happily scale to very large deployments, and there are now several open source options for horizontal scaleout as well.

There is no customer support, as this is an open source/open community product. That said, the PostgreSQL community is one of the best OSS communities in existence. Questions are answered quickly and professionally. The only thing I think the community could do better is recognizing that not all users are in a position to avoid or fix data anti-patterns.

It's not the simplest database to setup, but it's also not difficult at all. The only challenge is that there are many different packages offered by different OSs i.e. Red Hat/Centos, Debian, FreeBSD, Brew, MacPorts, etc), and they all have slight differences. This can lead to some problems during install, but they're not difficult to fix.

I've used Oracle, DB2, Sybase and MSSQL. The only one that comes close to PostgreSQL is Oracle, and only because of the large set of developer tools it offers. But, it's very difficult to manage and extremely expensive.

Always hire an expert to advise you on production database deployment. Similar to security, mistakes in this area have the potential to seriously impact your business. Postgres is free, but it can be difficult to hire experienced PostgreSQL people. There is a silver lining to that, as if you can find someone with five to 10 years experience then odds are very good and very dedicated to their craft and aren't interested in just punching a clock. You can certainly find those types of people for other products, but relatively speaking they're much rarer.

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!

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.

Open source products represent no cost to the organization and the basic features are sufficient to fulfill our needs.

• Cost savings
• Easy spin off for new environments

The only feature where I can see an area of improvement is with the partitioning. As soon as you implement partitioning, all your relationships are no longer supported since the PK-FK relationship is no longer supported and you need to look for options or database changes to supported with secondary tables, database rules or triggers.

I've used this solution for two years. We also use the EnterpriseDB version of PostgreSQL.

There were no issues with the deployment.

We had no issues with the performance.

It's been able to scale for our needs.

We have no external services.

We haven't used any other open-source service, but we have engaged Enterprise DB for enhancing our monitoring but there was no need to do so.

I wasn't in my current organisation when it was implemented.

We use the open source versions of PostgreSQL so there is no expense for licensing.

Do continuous testing and research on new features as they have an excellence performance response.

In my experience, the most valuable features of PostgreSQL are streaming replication, rich indexes support, extensibility and NoSQL features such as hstore and JSONB. This features are very mature and stable, we use them in many projects, they're predictable, always work as expected and without problems.

In future releases I would like to see built-in realization of multi-master cluster with sharding, effective partitioning, incremental backup, optimizations for SSD, connection pool facilities, and built-in replication for tables and databases.

I've used this solution for five years.

There are no issues with deployment. Postgres has a very verbose and clear documentation and install instructions.

From a scalability point of view, there are no difficulties. It works out-of-box without any third party tools, but streaming replication allows you to scale read-only workloads. For write scalability, Postgres-XC or Postgres-XL should be used.

I don't use any services and technical support, and th community's support is very helpful, friendly and the members have rich experience with PostgreSQL.

I don't use any similar solutions such as Microsoft SQL, Oracle, or MySQL.

The initial setup is simple and doesn't take a long time, but in serious projects, PostgreSQL requires additional configuration optimizations as do the other RDBMS.

We did it all in-house. You should read all the official documentation as all the answers are there.

PostgreSQL is an amazing product, very stable, predictable and reliable with rich set of features.

This database is highly reliable and offers excellent disaster recovery. In short, I can depend on it to be available and operational.

As we’ve used this since our founding, I cannot speak to how it has improved any function.

The development team has been teasing me with talk of multi-master capability for some time. Their latest release, 9.5.3, does offer some asynchronous capability, but I really want synchronous multi-mastering as that would allow horizontal scaling with much more capability.

Current bidirectional support is limited to the functions provided by a third party integrator. The extension does not offer real-time update guarantees nor does it support DDL updates (schema changes). This is quite unlike the current unidirectional replication scheme, where DDL updates are processed, and there is a way to guarantee real-time updates so the slave server can function as a hot standby. With BDR (bidirectional replication) this is not possible. I understand that in all respects, true bidirectional replication is the holy grail of databases as would give any server in a cluster the ability to take over as a single master without any transaction loss.

I've used this solution for more than 10 years.

There were no issues with the deployment.

I have in the past before the code base had stabilized. Certain procedures just didn’t operate reliably and some internal parameters were just too small and caused problems with large data tables.

It's been able to scale for our needs.

Well, it’s open source so mileage varies, but generally I haven’t had problems. Of course being open source, I can and have looked through the database source code and found the answers to problems I was experiencing.

I have used MySQL, another open source product now controlled by Oracle. It’s reasonably fast and OK for simple databases, but it lacks transactional isolation and its replication setup does not enforce a true master/slave configuration.

It is rather complex to set up correctly. The configuration file is over 400 lines in length and many parameters have only vaguely defined suggestions. Changing a single parameter can have unintended consequences.

Strictly in-house, and I would say anyone attempting implementation should hire the expertise to get the system correct.

Obviously pricing and licensing is non-existent, but the costs need to include the expense of in-house expertise, either employees or consultants.

PostgreSQL is an enterprise capable database very similar to many commercial offerings, but be prepared to either pay for consulting or a long period or experimentation to get the configuration proper.

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.

PostgreSQL is probably the most SQL-standard-compliant RDBMS on the market. It also goes way beyond standard relational paradigm combining key-value stores, arrays, and columnar stores into a single engine. With the introduction of Foreign Data Wrappers it also enables connecting various different data sources to the database, so it's possible to have, for example, a CSV file-backed foreign tables or to import a MSSQL schema into PostgreSQL.

PostgreSQL allows us to have a single database engine used for OLTP and OLAP workloads, for relational and non-relational data. Its robust and battlefield-proven replication makes us sleep better.

Logical replication would be a major improvement and it's already being worked on. It'll enable true multi-master replication and active-active setups. More OLAP-related performance improvements are also on the way with parallel query processing and parallel background workers being to most significant ones.

v9.5 came out at the end of last year, but I've used previous versions as well. At the moment all the new deployments I'm installing are based on 9.5 since developers are very keen to adopt it and administering it is a breeze.

PostgreSQL is the most advanced open source database in the world and therefore is considered by some to be complicated, but it's not. Deployment is easily done in major GNU/Linux distros.

PostgreSQL is rock-solid-stable, once set up and configured correctly it just continues to work.

There are plenty of clustering solution/ideas that enable horizontal scalability.

PostgreSQL has a very active community and in most cases that's enough of a support. There are a few commercially focused companies, and a lot of freelance consultants [with the writer of this amongst them]. Bugs are always resolved in a timely manner.

If you can type "apt-get install postgresql", you can consider yourself expert in installing PostgreSQL.

While the initial setup is easily done by any member of Ops team, it's important to have a dedicated DBA resource to take care of it. PostgreSQL has superb documentation, it is probably the best documented IT project. We have an in-house team and almost never have to use external consultants. PostgreSQL is very much different from the most popular RDBMS, so it's best to seek a PostgreSQL-focused professional for the in-house team.

I work with few other RDBMSs, but nothing compares to PostgreSQL when it comes to ACID and SQL compliance, stability and the ease of administration.

Get a dedicated, PostgreSQL-focused resource, it's hard to convert DBAs with background in other denominations.