PostgreSQL Reviews

• Free and open-source RDBMS, with a permissive license
• ACID compliance
• Multi-version concurrency control
• Custom data types
• Array data types
• PL/Python stored procedures

Back in the day, MySQL had storage problems with InnoDB (everything in a single file), and we wanted ACID compliance. So we decided to use PostgreSQL for that, and it helped us achieve that goal. PostgreSQL's feature set was excellent for our needs, and we didn't want an expensive (meaning hardware utilization) RDBMS. Fit like a glove.

There's always room for improvement. Better SELECT performance is something that PostgreSQL could really benefit from. Replication should also be made easier. PostgreSQL also lacks a good tool like MySQL Workbench. PgAdmin3 works, but it's funky and crashes sometimes.

We've been using PostgreSQL in production since version 8.4, in 2010.

I have not encountered any deployment, stability or scalability issues. It's been running since version 8.4, updating one version at a time (9.0, then 9.1 until 9.4). Database is currently at 6GB, works without a hitch.

I have never used or never needed technical support. StackOverflow covered all our needs on this scenario.

Up to that point, we used MySQL. The decision to change came with a new version being written from scratch, and PostgreSQL being better suited for our needs.

The initial setup was somewhat complex. We had to import the old database, which was in MySQL. Most tables were rewritten, and the team was not used to PostgreSQL at that time, so there was a small cultural impact.

Implementation was completely in-house. On our case, it was much better to train the team to use a new RDBMS than to use external consultant; after all, our team is a development team.

Since it's completely free, the ROI means only the time spent by the team to get the database up and running, and the time maintaining it. I'd say it doesn't compare with any other solution I've worked with before.

PostgreSQL has extensive and comprehensive documentation. Chances are that you'll find your answers there for 99% of the cases. For those answers you don't find, you can always go to StackOverflow. If you're not a DBA or a programmer, I'd suggest hiring external help, as with all the cases with databases (RDBMS or not).

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.

Strong enforcement of data types, because it can catch many errors and mistakes and protects data. Standard conformance, because in the end you are not locked to single vendor.

We used MySQL for many tasks, because there were simply more documentation available, but while using it, we found many serious weaknesses with it like no data validation even for string length, no transactions, etc. PostgreSQL catches a lot of things that MySQL didn't because it is serious about the data it protects!

It needs more parallelism for big tables. This is already in PostgreSQL 9.6 beta so things are looking promising.

We've been using it in production since 1999.

We have had no major issues with the deployment, but tweaking does need to be done.

There have been no performance issues.

It's been able to scale for our needs.

Excellent mailing lists with active developers. Once I sent them my query which was about slow performance due to double sorting (group by, order by), and the fix for it went into PostgreSQL 7.4, because Tom Lane noticed that in such cases PostgreSQL should not do two sorts. So after upgrading to 7.4 things got way faster without touching the code at all.

We previously used MySQL. PostgreSQL tries to solve things in the correct way for all platforms, all file systems, and all users. In the end, this means you get a better working and more stable system. They try to stay away from hacks and other non-portable or limited solutions and prefer to work inside the system. For example, an operating system already does many optimizations so why would one want to reinvent things with raw file systems, etc. like Oracle tried to do in the past?

Defaults for PostgreSQL are very low. In almost all situations one has to do some tweaking to make it perform better. It does not take much time to do it at first, but has to be done!

I did it myself with help from the internet. For beginners, I would advise you to read the documentation that is available. Also, you should read some books such as "PostgreSQL: Up and Running, 2nd Edition". "PostgreSQL Administration Essentials", "PostgreSQL 9 Administration Cookbook, 2nd Edition". Alternatively, you could look into getting professional help if you are in hurry.

Explore this new world. PostgreSQL has taken a quantum leap over the last 20 years, and now it seriously threatens more established database vendors.

GIS function. Geography is a very important function/dimension for our f. Postgres helps analyse that easily.

It provides access to data for analytics. It has a lot of free tools available for data access, and has easy integration with a lot of visualization tools such as QlikView and Tableau.

They need to develop an easy way to do a cross-DB query and some basic report visuals and alert systems would make it awesome, if they are possible.

>2 years

We had no deployment issues.

The product is quite stable.

There's been no issues with scaling it for our needs.

It has a great support community.

It's very easy, and you only need to familiarize yourself with its file structure. Sometimes you need to write your own plugin, so sometimes it is better to have it implemented by a vendor.

It's free as it's open source.

For me all SQL tools/products are similar, except for a few important differences like GIS functions in PostgreSQL, and programming abilities in Oracle PL/SQL, etc.

Go ahead with the product which has the best use case for your organization. Cost is never an issue.

PostgreSQL provides a lot of valuable documentation and there's widespread usage of it.

I use it for personal projects. It's been really easy to learn and it's been useful since ramping up it use.

Although there's documentation out there, it needs even better documentation. Another thing that would be helpful are examples of usage of it with JavaScript.

I've used it for six months.

There were no issues with the deployment.

We have had no issues with the stability.

We had no issues scaling it for our needs.

I haven't had to contact technical support. There's been no reason to do so.

It was straightforward and well integrated into Rails applications across open source world.

Compare and contrast various database optimizations based on your needs. And when you come across issues, don't reinvent the wheel -- someone has probably had a similar problem to your own.

By using PostgreSQL, it was easy to get all the developers configured and running. With using it as our back-end for data storage, our company isn’t worried about data loss or data integrity, especially with snapshots and WAL. Our company is also able to run reports and do analytics off data in custom tables.

PostgreSQL does a great job with scalability and performance. Since we are using Django/Python – it works great with PostgreSQL as well. The current features that really help us are Full-Text Search, Array Fields, and JSON Fields.

The only thing I would really want/need to improve is pgAdmin3. pgAdmin3 is a nice tool for SQL Admin and Queries. But, I wish it would allow multiple queries to be run and displayed in the output pane.

Also, it would be amazing if Full-Text Search would work on encrypted data, but I don’t know how that would be possible with any kind of speed.

In regard to pgAdmin 3, there are so many times I’m in one window running different queries. In Microsoft SQL Server, you can select and execute multiple queries and they are shown in the output pane as separate sections. In pgAdmin3, I have to open multiple windows and execute separate queries and jump from window to window looking at / comparing results.

For the Search/Encryption, PostgreSQL supports having certain fields encrypted in the database (https://www.postgresql.org/doc...). It also supports Full Text Search (https://www.postgresql.org/doc...). But, if we encrypt the fields where the lexemes are stored, search won’t work. (Some of the lexemes could give too much information if a user got their hands on the table.)

I have used this solution for three years.

Everything we have needed, we’ve been able to find on https://www.postgresql.org/ or StackOverflow.

We had used Microsoft SQL Server in our previous company. But, the licensing terms kept getting more and more onerous. We started looking at PostgreSQL from the reviews and recommendations, especially since it was open source and Amazon RDS started supporting it.

Initial setup was very straightforward. EnterpriseDB has a great graphical installer to help install on our Dev machines (MacBook Pros). And, AWS RDS makes it is very easy to get set up as well. It allows us to spend our time developing, where our expertise is.

Our initial implementation was done in-house. As long as you follow the step-by-step directions, everything worked great. We also have a managed services company that helps manage the PROD/Staging configuration as well.

Pricing/licensing is the reason we went with PostgreSQL. As a startup, every dollar counts and PostgreSQL has enabled to us to have an enterprise solution at a fraction of the cost of Oracle and Microsoft SQL Server.

PostgreSQL is an amazing product. Very easy to implement and there are many libraries to make it easy to use PostgreSQL as a back-end database solution, no matter what coding language you are using.

• Locking: Tables very rarely get locked, while with MySQL, it’s a frequent problem.
• Easy backup and restore
• Reporting uses Windows functions / aggregates function
• Partitioning

By implementing PostgreSQL, organizational databases get stabilized, no locking issues occur and report extraction is faster.

• Replication: Table-level replication should be built-in. However, we can do this now by using Slony.
• Backup: Currently, an incremental backup feature is not available. It should be added.
• A simple-to-use PG cluster monitoring dashboard would provide an extra advantage.

So far, it’s the best database I have ever used.

• PostgreSQL streaming replication
• PITR-based backups
• CTE SQL
• SQL windowing functions

• Streaming replication (or similar) disconnected from the version, so we can use it for upgrades (i.e., a 9.3 version master and a 9.5 slave)
• Better scaling options such as sharding tools, parallel query and star schema-aware queries
• Better partitioning support to include better / packaged partition management and the ability for the base table to return the number of rows affected even if the affected rows are in a partition

Get some expert help; I cannot stress this enough. We often walk into DB setups and architectures that are a wreck because the team "knew enough to be dangerous". Even more often, we see database isolation, meaning the DB is not connected to the enterprise data architecture. That mistake leads to expensive problems down the road.

It's an open-source, license-free product that can go head to head with the likes of Oracle & DB2 and hold its own in terms of features and performance, in many cases beating the competition.