PostgreSQL Reviews

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

PostGres is a fantastic modern RDBMS and its open nature allows you to get as low level as you need. You can define functionality, you can call from SQL and dig deep into the query planner with it's excellent explain functionality. The true open community is loaded with helpful people who believe in OSS. Every feature in PG is first, present, but secondly mature and just works. You may have bugs in your code but PGSQL will never be the cause of it.

It drives our enterprise architecture we are building.

The only thing that could potentially be improved is PGAdmin3, the DB Client that's has not been updated in quite a while. PostGres keeps ahead of the curve on it's feature set. For instance the new JSON column that's come out recently to provide nosql functionality that has been benchmarked to outperform mongo.

We had no deployment issues.

The product is quite stable, and provides awesome performance.

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

It has a great support community.

I started with this product.

It's very straightforward initial configuration if you start with your distro packeges.

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.

It's go good reliability and is very compliant with standards. If you are installing relational DB you likely know how to use one. If you're not familiar with RDBMS's make sure you look into and use the features of the DB like views etc. They all serve a purpose and will improve your development if leveraged properly.Huge feature set.

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.

We use the solution for media purposes. We manage the sites of one of the largest sports business papers and multiple TV channels. So, we develop the websites.

We are increasingly using their support for JSON, which we find to be very complete, something I made use of in the past. The solution provides complete support in terms of the SQL dialect and behaves nicely when it comes to transactions. One can change the database structure transactionally. This is one of the few databases that allows this. I like it. 

The solution is comparable in sophistication with that of Oracle. Each product has a few things less and more than the other. We also like that the solution is open source. We have good performance with a small footprint. It's rather nice. It's very robust.

The solution could be improved through an upgrade to the latest version. 

A better graphic user-interface would be nice to see. 

There is nothing I particularly dislike about the solution. The data propagation in master-slave configurations would be a good example. This is one of the features that I understood the least, yet we have it working and use it to propagate from the content management system database to the multiple publishing databases. 

This said, I would like this propagation feature to be simplified for new users and to come with better explanation. However, I will refrain from giving criticism on this point, as I do not know if they already handled this in the last version. Overall, I have only praise for the solution.

I cannot point to anything in particular that we are missing out on at the moment. What comes to mind are features that I have yet to try, although I don't  have any wish lists for PostgreSQL at the moment. I don't know how it stacks up when it comes to the importing and exporting of data. For databases involving this, we just make use of Redshift, which is verified from PostgreSQL and developed by Amazon. 

I have been using PostgreSQL for a couple of years.

The solution is very stable. We have databases that have been running for years.

We have scaled the solution just to three slave machines, but it works well when it comes to master and slave. 

Mostly, support consists of the community and there are several consultancies, should the need arise, although we have never had use of these. There have been no issues on this end. Community support has always been sufficient for us. 

On a single machine, the initial setup is extremely easy. I also find configuration to be very simple. It is similar to MySQL in that a person must know what he wants when it comes to setting up the solution, in which certain features would come into play. Setting it up in a different way will involve the use of multiple search engines. 

With the solution, one installs it and whatever he tunes is optional. Of course, he would have to play with the configurations if he wishes to have specific personality, such as cluster configurations, or tuning for very demanding performance. Overall, for small things or development, one need only install it, start it and it's done. 

While the length of the deployment varies with the configuration, a simple one will take a couple of minutes. 

We deploy the solution both on-premises and on AWS. 

I had my doubts about the functionality before joining this company, as it seemed very complex. It turns out that the solution is actually very simple to set up and we have it working all the time without any problems. It survives the network partitions, so we like this very much. 

My advice is that a person just try it and use it. For me, it beats out JSON and is superior to MongoDB. It works in a completely different way. But, overall, I would rather use PostgreSQL when it comes to starting and manipulating JSON and it boasts superior integrity and performance. Of course, there are specific things that MongoDB does differently. A person's mileage may vary, depending on what he wishes to accomplish. 

I rate PostgreSQL as a nine out of ten and I choose to knock it down a point only because it could use a better graphic user-interface. 

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.

It is easy grow it from a small environment to a large one.

We use PostgreSQL as the basic tool for offering our data warehouse and BI solutions. This way my customers have a free tool and I can offer a lower price for our services.

It should have a better native client tool to manage the databases.

I've been using it for nine years.

We have had no issues with the deployment.

There have been no performance issues.

It's been able to scale for our needs.

I've never used it , but this tool has a big community and they are always open to helping.

We had some problems with bigger customers using MySQL so we moved to PostgreSQL.

It's very straightforward if you are using the default configurations. It can become complex when you begin to change these configurations to adapt it to fit your environment.

In-house because we a are a technology company. I always advise to look for a consulting company, sometimes the default configuration is not enough and the tool can become a bottleneck if it isn't properly configured.

My advice is to always begin with the free licenses, and if you see that your tool is becoming a strategic solution, you can look into obtaining professional licenses.

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

It is fast, compact, flexible, and scalable. I like the fact it is not tied directly to a server OS, such as Microsoft SQL Server. Being open source it is very budget continuous for our clients.

There are a few little odds and ends like all SQL servers that differ from other SQL servers. The way it handles logical, the fact it does not support primary keys on views etc. My experience is all SQL servers have little differences from each other. PostgreSQL is far more robust and built for production use than MySQL which I have also used.

I would love to have primary keys on views. This function missing has made PostgreSQL harder than need be with Microsoft Access as a front end.

I have been using this as a back end server for various front end applications for about five years now.

We have had no issues with the deployment.

There have been no issues with the stability.

There have been no issues scaling it.

Like all open source community supported products, the technical support is hit and miss. I have found tho, there is a large user base and I can usually get good ideas how to do a work around within a few hours, day or two at the most.

We used Oracle, MySQL, Microsoft SQL Server. Oracle and Microsoft SQL Server were simply too expensive for smaller customers. MySQL had too many short comings to make it a workable solution.

The initial setup was pretty straightforward. A lot of the setup for a typical installation is a Linux scripted Boot-Install disk. Answer a few questions and you are off to the races.

Did the implementation in house. Not for everyone, but then, if you are installing and utilizing a standalone SQL Server you have to be a pretty computer savvy person.

Being open source this is not really applicable.

PostgreSQL is a great SQL database, powerful, flexible, but it is not something to be considered over other things. The most important issue for a database, if what back end do your mission critical front ends support. With PostgreSQL we found next to nothing we would not do with other open source applications.