PostgreSQL Reviews

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.

PostgreSQL is the only open source and multi-functional database solution out in the market today. I have used it to replace Oracle (RDBMS) up to MongoDB (Document DB). Postgres has very rich SQL and NoSQL features that gives it a special place in database industry. It’s easy configure and manage features helped to increase adoption in last decade or so.

PostgreSQL is the most flexible database I have worked in my career. For example, when I need geographical data processing for my application, I can use PostGIS. It is the best GIS solution out in the market, by installing extension the extension onto the database. Additionally, PostgreSQL's full text search functionality helped a quite a number of times to avoid introducing another system for text search and use PostgreSQL.

PostgreSQL has introduced number of new features to achieve out of the box multi-master replication and reach JSONB features, horizontal and vertical scalability and parallelization features. I’d like to see them to be production ready. As the number of users of application grows, the multi-master replication will helpful to replicate systems across the continents. We have started using JSONB in number of application, I would like to see some extended features to make JSONB data type more reachable. The horizontal/vertical scalability & parallelization features will help our big data analytics processes faster to improve application response time.

I've used it for approximately 10 years.

I have experience working with over dozen of database and datastores in production environments but PostgreSQL has been the most stable database I have worked so far.

It is missing some key scalability features such as sharding and automatic failover, but the Postgres developers are working on adding these features.

Postgres community is very thriving and Postgres ecosystem is very strong. The product is open source but it has the best documentation and readable code among other open source products. The turnaround time for logged bug is much faster than some of the commercial vendor’s support team. Additionally, there are a number of PostgreSQL professional support companies in the US and all over world.

I used to be an Oracle DBA over decade ago. I have used over dozen of database solutions ranging from MySQL to MongoDB in the distributed production environments but Postgres provides superior features but not limited to; extendibility, performance, scalability, analytics queries.

PostgreSQL is easy to setup compare to any other commercial RDBMS out there in market. It is easy to install and configure.

Postgres has great documentation and various open source tools available for maintenance. However, it is recommended to work with Postgres consulting services companies to expedite design and implementation.

PostgreSQL is truly open source database system so the licensing cost is zero. If you are migrating from any commercial database system, you are saving licensing and recurring support costs.

If you don’t have experience with PostgreSQL, I recommend to attend some of the local PostgreSQL user group meetups and/or conferences to learn how it is being used. If you need help discussing about the solution, you can reach to any of the Postgres consulting services company.

From our use of it, its stability and performance are the best features. The fact that there's no downtime and that it functions quickly are very important to our workflow and business.

We're in the evaluation period at my current company, so we haven't really seen improvement to our functioning.

The multi-master replication feature needs improvement.

I've used it for eight years now.

We've had issues with deployment, but I can't share the details.

We've had issues with stability, but I can't share the details.

We've had issues with scalability, but I can't share the details.

We are running the open source version and haven't purchased technical support.

Yes, we evaluated other solutions, and we are moving away from PostgreSQL after the evaluation period.

The initial setup is very straightforward.

The implementation was done with our in-house team. My advice is to get training.

PostgreSQL, especially the latest versions, comes with a very rich set of server side programming tools, while providing speed, data consistency and the transaction's coherence.

This is a very wide answer, but this large environment is providing fast solutions to various needs and I see this the main power.

I have a quick example about how it reduced the amount of backend code and also improved the application's performance. When you are in a scenario where your application has an input, and based on that, you have to do several back and forth exchanges with the database to get more information or do data changes, you can do that transactionally by using a stored procedure.

Some may say that this puts logic in the database, and yes it does, but it's the most efficient way to get the right output. By exploiting the PL/PgSQL capabilities it can be done and maintained more efficiently than usual backend code.

Another reason for improvement is that PL/PgSQL is a type safe language and this reduces considerably the amount of errors and even the functional flow of the application. Stored procedures are transactional, so either everything goes well, or an error happens.

Starting with v9 it can be seen an intensive activity to bring more features, more performance or productivity. I would like to see it be more reliable, and easier if possible, to make PostgreSQL clusters - more machines working together as a single instance .Providing an autonomous solution to share data across machines or replicate when it's needed. I would like to see horizontal scaling, up and down, made easier, and if something happens (I've rarely encounter cases after version 8), easier recovery from database general failure.

I have been using PostgreSQL from v7.2 through v9.4, over more than decade. I have deployed it on both Linux and Windows machines.

My first interaction was in October 2002 and since then I've continued to use it for various applications or services, varying from a few tens of thousands of records per table to hundreds of millions and more complex deployments.

The source for Linux machines were usually ("usually" because in the beginning you had to compile certain versions yourself, especially for custom setups) the operating system's repositories and for Windows the packages prepared on the official PostgreSQL website.

I've experienced stability issues on versions 7 and 8, but setup properly none (in my case) on version 9.

Database mirroring was very impressive five to seven years ago, and since then many things have changed. At that time, horizontal scalability wasn't mature enough and we preferred to manage multiple instances independently, something that is going on today. One of my next projects is to test the limits of todays solutions for PostgreSQL clusters.

First of all I think PostgreSQL's documentation is very rich (still missing more complex examples or aspects) and provides a lot of answers. Then you may find a large community and forums. And more professional people able to help.

I've always followed this path before calling a certain customer service or support, of course with the cost of investing a lot of personal time to understand things and apply measures. But this was a personal curiosity and pleasure.

I've used a larger set of databases (including the most well-known and a few more exotic) and setups. Definitively PostgreSQL is a serious contender at the top of the list. I chose it because it's fast, reliable, rich in functionality, and it has no commercial costs for its acquisition.

Starting a simple database is straightforward, but when it comes to set up, machines for heavy duty operations, read or write, there is a consistent learning curve to take into consideration.

PostgreSQL is a complex database, but once your start mastering its features you discover that things work.

I have always implemented in-house and sometimes I've looked around for vendor sources just to understand with what they come more.

Definitiely they help reduce the learning curve and there are promises for richer scalability options.

In the cases I've seen ROI was very good and it touched visible aspects from reduced ETA of developed applications, to better performance, easier maintenance and faster support.

The investment was in proper hardware and learning curve to master the database. Charging for expertise to deploy PostgreSQL depends on the expected setup, but in all cases, my choice would be to include a database specialist as early as possible within the development team.

The reason is that pure developers tend to rely on database power, making poorly optimized queries or choosing bad structures that explode later. The data warehouse team then have to clean it up, causing a loss for everyone.

This is a very good product, and I'm very pleased, especially with the latest versions. I haven't found the perfect database yet, but definitively PostgreSQL is a candidate to consider, especially if you take into account that comes for free and is open source.

I had many debates about PostgreSQL and I've never seen yet someone getting to know it and complaining about it. It simply helps and works, but you have to be good at it. Going for commercial solutions might bring serious costs and a feeling of confidence, but this database is not only for try or start, it's reliable and well done.

• It's open source product not need to license, so economic
• It provides a graphical interface (pgAdmin) simple, intuitive and efficient
• Simple installation 
• It does not consume a lot of resources
• Really suitable for business n-tier solutions
• Rich documentation
• An interactive community

The strength of this product is set in the timeliness of SELECT queries with lots of joins. compared with other DBMS, it is really optimized for joins.

I think that due to the lack of functionality for data warehousing, it is more suitable for operational information systems instead of BI systems. Besides, it only allows Relational Online Analytical Processing (ROLAP) not Multidimensional Online Analytical Processing (MOLAP).

There have been no issues with the deployment.

We have had no issues with the stability.

It's been able to scale for our needs.

Because we use it in many information systems (Financial, Human Resources, Inventory Management) in several large companies with significant data flow, we have not had problems. It was effective as a product.

Read the product documentation well and know the configuration parameters because just one incorrect parameter can affect the entire database.

• Confidentiality
• Integrity
• Availability
• Bug free

I like to work with a piece of software that is bug free and doesn't required to be launched in order that users will find a couple of bugs in the coming weeks and that the company has to fix it.

It helped me to find an easy and inexpensive solution for databases

It would be interesting to have a cloud based database instead of having to install it on any single machine.

I've used it for approximately one to two years.

I've had no issues deploying it.

The stability was an issue, because when coding under Eclipse with Java, some errors occurred while trying to connect to the database, so troubleshooting may be difficult, since you don't know if it's a Java coding issue or a PostgreSQL translation issue.

There have been no issues scaling it.

I never used any customer service or technical support during that time. I used to find alternatives to my issues.

Since Oracle was expensive for a company business an inexpensive way was to focus on PostgreSQL.

The initial setup was straightforward, just activating various modules was more complex.

We did it in-house.

I saved money instead of using the Oracle solution, which might be more secure than PostgreSQL in various ways.

You need to find a lot of time in order to find all functionality and get used to the PostgreSQL syntax Be patient, look for various forums and do learning by doing.

• Updatable views (also over multiple tables)
• Array and JSON fields
• Point-in-time backup and recovery (WAL files archiving)

I find, sometimes, that it is too restrictive in cross-table/view constraints. This is very annoying as I needed to change a field definition from VARCHAR(10) to VARCHAR(30) and, having a group of views depend in it, the only solution was to implement a function that would:

• Read the view definitions
• Store them
• Delete the views
• Update the field definition
• Recreate the views

It took me like three or four hours (and caused a lot of stress) to make such a simple change. To me it looks a bit too overkill, especially nowadays that application requirements and implementation change so often.

I have used it for one and a half years.

There were no problems with deployment.

The app hasn’t had the need to scale much yet.

It was quite straightforward.

I implemented it myself and don’t have any particular advice about it. Today I would consider implementing it via Docker.

I've only used online open source resources and would say there's not as much as there is for MySQL. Sometimes it took me some time to find a good solution to the more unusual scenarios

PostgreSQL gives you much more flexibility because it's open source.

It improves the query performance a lot and helped in some real time and analytic reporting

Sometimes it hangs and then we need to stop and start the services again

I've used it for three years.

We've had no issues with the deployment.

There have been no stability issues.

We have had no issues scaling it.

7.5/10

7.5/10

No other solution was used.

It was straightforward.

We used a vendor team.

• Stored Procedures
• Full Text Search

One of our products crawls information from different web sites and then detects if some keywords are there based on a business logic. The business logic was programmed in Stored Procedures using Full Text Search to detect keywords that we wanted in the extracted text. Doing it this way, we keep the logic in the database and we only need to constructs need crawlers that feed the database with more text to process.

The Full Text Search functionality saved us a lot of time because we didn’t need to program that ourselves.

We don’t have any real database expert in the company, we are mostly developers. So I wouldn’t know if something would need improvement or we just haven’t learn how to use it properly yet.

However, less advanced programmers may have a bit of a learning curve. Also, it will make a difference with your database only once you get past the basic levels.

I've used it for over three years.

We've had no issues with the deployment.

Very stable product.

There have been no issues with the stability.

Haven’t try it yet. We solve our problems ourselves for the moment.

Straightforward, however, we are all advanced programmers so the learning curve might have been easier for us.

In-house. There is a lot of good information on the web and stackoverflow.

PostgreSQL is free, so great ROI!

We compared it to MySQL, Oracle and we though PostgreSQL Full Text Search functionality was the best for what we needed.

At basic levels the database won’t do much difference, focus first in learning how to build queries properly, create index, etc.

An image of our product achieved with Full Text Search.

Common Table Expressions(CTEs). It's powerfull, easy to write and read and very flexible.

JSONB (Binary JSON storage), because I can have both relational and non-relation data storage at the same time with this data type. In addition, by using Generalized Inverted Indexes (GIN) it supports fast lookups and simple expression search queries.

Replication is not yet as well implemented as in MySQL.

I've been using it for one year and five months

There are some issues around different OS, but not a big problem.

There are some issues around different OS, but not a big problem.

There are some issues around different OS, but not a big problem.

The documentation could be written better, but there is a huge community committed to help.

I used MySQL, but for safety and consistency issues, I moved to PostgreSQL

Straightforward, easy and intuitive.

In a vendor team, we develop products for different segments stores. In the implementation, keep in mind the configurations and platforms that are available, it certainly will save time and avoid potential problems.

Currently this is one of the best solutions on the market. It is a tool without cost, powerful, easy to learn and with a large active community.