PostgreSQL Reviews

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.

We often use PostgreSQL for operations monitoring because we are a manufacturing company.

We often find the solution's datetime datatype challenging.

I have been using PostgreSQL for four years and five months.

PostgreSQL is a stable solution, and we haven’t faced any performance issues.

We faced no difficulty in installing PostgreSQL.

It took us five minutes to deploy the solution.

Overall, I rate PostgreSQL an eight out of ten.

We are using it as a database to store information.

Postgres SQL is quite a good database.

The performance is good.

I have noticed that user and access management should be improved. Connection pooling should be improved. We rely on connection pooling.

Monitoring is incompatible. It is open source. To advance, you must access the internet and download and test various other tools, or develop your own tools. With Microsoft server, it is one single platform that provides you with everything, but with Postgre you have to install or check different tools to integrate with it. That's the annoyance, but it's still the way open source technology works.

I would like to see better management in PostgreSQL.

PostgreSQL is easy to scale.

We have a medium-sized company.

We don't have technical support. It is community-based. We get assistance through Github.

We have been working with Microsoft SQL.

The main difference between SQL and Postgre is that Postgre is open source. It's completely free.

It's very simple to set up.

Postgre is open source. It is almost completely free.

The community version of Postgre is basically free.

We are utilizing the database's active native security features. As a result, we currently have no need for any external security tools. We had, but we worked around it.

The advice would be to go with a managed Postgre. If you're going to install Postgre in the cloud, for example, it's better to go with a managed Postgre rather than handling everything on our own.

I would rate PostgreSQL a nine out of ten.

I have implemented costing models. I use it to capture item costs and then do calculations to compare costs.

The built-in code procedural language is the most valuable. It has a built-in layer for code procedures. 

Its installation is very easy and quick, and it is free. It is also stable, and its performance is also good.

PostgreSQL doesn't have a feature for temporal SQL, which is useful for selecting version(s) of a row. 

Specifically the syntax 

SELECT 

FROM <table> FOR SYSTEM_TIME AS OF ...

This feature should be included in PostgreSQL. This feature is available in MariaDB, SQL Server, Oracle Database, and DB2. 

I have been using this solution for six to seven years.

It is stable.

For my use case, it was good enough. I didn't use cluster or other such things. In my previous organization, we had 10 and 20 users. In my current organization, we don't have any other users.

I haven't used the paid support. I always find information from open forums and technical guys on the web.

I was previously working in a research organization, which favored open source. I have also used Oracle, Sybase, Microsoft SQL Server, and Ingres databases.

Its installation is very easy and quick. I am running it on Linux. It took a few minutes to install it.

I do it myself. I have been doing it for a long time. For its deployment and maintenance, one DevOps person is sufficient.

It is free, but if you need support, you can go for the commercial version called EnterpriseDB. They provide paid support, and they can even do hosting for you if you want standby and support.

For our current use case, I'm evaluating PostgreSQL versus MariaDB. I am probably going to use MariaDB because I need the temporal SQL feature, which is not available in PostgreSQL.

I would 100% recommend this solution to others. I would rate PostgreSQL a nine out of ten.

• Integration with various programming languages
• Partial indexes
• Online backups/recovery
• Replication
• Hot standby
• Cascading replication
• Partitioning
• Performance

This is an open-source product with advanced features that support OLTP/OLAP applications with the following benefits that helps organizations grow:

• No recurring licensing cost
• Huge cost savings forever
• No vendor lock in
• One-time migration cost
• Yearly major releases
• Increase in profit margins
• Completely open source
• Community-based FREE support available
• Commercial support option

The product has room for improvement with horizontal scalability and multi-master replication options, where community work is already in progress. These features will greatly benefit customers by balancing the load between servers, resulting in great performance improvement, scalability and high availability at a fraction of the cost.

I have used it for more than 10 years.

Over the last 10 years, I have used it to handle terabytes of data supporting OLTP applications and have hardly come across any stability or scalability issues with PostgreSQL.

My company, Shreeyansh, provides high-quality, 24X7 database services along with a commercial support option. We scale our services 9/10. Customers can opt for community-based support as well.

Customers may have straightforward or complex environments. However, it's totally based on the technology in use and the amount of money spent for running their business applications.

We have special expertise in providing various database solutions to our global customers and we implement customer solutions with help of our in-house DBAs.

PostgreSQL is written in ANCI C, fulfilling all of the ACID properties other proprietary databases support. Most of the customers who use proprietary database solutions to their business applications prefer to move away from proprietary licensed databases to open-source databases to save huge amounts of recurring licensing costs resulting in huge profit margins. Customer choose PostgreSQL for its rich feature list, open source, no recurring software licensing costs, no vendor lock-in and various choices for the best commercial support and community-based support available.

I strongly recommend this product, with no recurring licensing liabilities with community support and with optional commercial support available. Shreeyansh Technologies provides various quality database services in 24X7 model to support our global customers.

• 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).

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.

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.