PostgreSQL Reviews

The new JSON data type that allows to use some NoSQL-like functionality.

This is great because brings some of the most valuable features of NoSQL databases to relational databases. You can have a column with JSON datatype and then query that JSON inside your regular SQL queries. 

So basically, you are mixing together the relational and NoSQL world in just one database, one powerful solution. 

We use it as main database for our SaaS product.

Scalability;

Although PostgreSQL is known for handling very well large amounts of workload, NoSQL databases performs better when scaling. NoSQL databases were built with scalability in mind, so it´s a natural advantage. 

PostgreSQL must keep improving their scalability and ability to work in HA (high availability).

I've used this solution for four years. 

No. 

See answer to 'Room for Improvement' question. 

We had several performance issues with MySQL.

Yes, MySQL.

Explore all the features.

It works great out-of-the-box and it opens up many opportunities in project development.

I first install the regular version. I only configure complex things when they are needed.

I think that the product fully meets the needs of modern development. If there is something missing in it, then it is probably a too narrow profile function.

I've used this solution for two years.

There were no issues with stability.

There were no issues with scalability.

I would rate the technical documentation as an eight out of 10. I never spoke with the support team.

I used MySQL. I switched because at that time, because some things were complicated with MySQL. For example: scaling, sparse data JSON, and other issues.

Both projects have the same query syntax, and the transition for me was almost painless.

The setup was easy.

As far as I know, there are no problems with the license for free use.

I explored many different databases: Redis, MongoDB, MySQL, Elasticsearch, and others.

I use some of them in conjunction with PostgreSQL. However, if we are talking about relational databases, then I only use MySQL.

I think this is the only decent solution for a relational database in web development.

PostgreSQL is an open source database, so there is no associated licensing cost for the software and we always have a new version easily available. It runs on all major operating systems, although I have always used it on UNIX platforms.

It also supports storage of binary large objects, including pictures, sounds, or video. It is highly scalable, both in the sheer quantity of data it can manage and in the number of concurrent users it can accommodate.

PostgreSQL runs stored procedures in a lot of programming languages (Java, Perl, C/C++, etc.). It includes many built-in functions from basic math and string operations to cryptography and Oracle compatibility. Triggers and stored procedures can be written in C and loaded into the database as a library. PostgreSQL uses a multiple row data storage strategy called MVCC to make PostgreSQL extremely responsive in high volume environments. Allow hot backups.

I have worked at the Ministry of Economy in the IT area, for more than 20 years ago. Since then, the main developments have always used PostgreSQL for their robustness, reliability, stability, and conformity with the standard SQL.

I have noticed that it consumes a lot of resources. I would improve this aspect.

We had no issues. PostgreSQL statistically does not suffer falls, it simply works.

We had no issues. We had to modify some configurations but the impact was almost transparent.

All the obstacles that we encounter are solved with information obtained on websites. PostgreSQL has a community of thousands of users and professionals who contribute their experience, so I always have found a solution for all my issues.

I have used other solutions for over 20 years and the problem of licensing has been our biggest drawback because of the costs and dependence we require from the provider.

It is extremely simple. In addition, we have several databases in production so we always start with a configuration model already tested and reliable.

I recommend PostgreSQL without doubt because my experience of almost 20 years with this product has shown me that PostgreSQL has certain features that make it highly reliable: high scalability, robustness, available for multiple platforms, extensible with little effort and without additional cost, designed for high volume environments, easy to manage and extensive online support.

I recommend everyone to get into the PostgreSQL world, with no licensing costs. PostgreSQL uses a flexible and business-friendly license because it does not restrict the use of PostgreSQL with commercial and proprietary applications. Those who choose PostgreSQL forget the dependency on a provider, the price of the licenses and the changes in the license conditions.

We got carried away by the experience of a team member with experience in PostgreSQL and first we used the tool in applications of low concurrency of users but with storage of files pdf, doc and xls in the tables. We were surprised by the results. This is how we trust in PostgreSQL and we demand more and more. We always get good results. Sometimes we have had to migrate to a new version of PostgreSQL, but have done so without any problem(s).

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

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.

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.

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.

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/docs/9.5/static/encryption-options.html). It also supports Full Text Search (https://www.postgresql.org/docs/9.5/static/datatype-textsearch.html). 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.

So far, we haven’t had issues with deployment, stability or scalability.

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.

• Replication which enables us to use it for High Availability.
• The Foreign Data Wrapper means we can integrate it, and provide interoperability with other databases.
• Multi-master Replication helps us to distribute a database geographically without any hassle or performing maintenance for synchronization as this it is all done during the replication process.
• PostgreSQL has a cleanly designed object basis RDBMS, so there are many opportunities to hook/plugin the PostgreSQL to get more functionalities and features.

Before using PostgreSQL, we had a database issue that we were trying to solve with Oracle. However, Oracle is quite expensive and I heard from a colleague that Oracle increases their charges year on year.

There are many places that it could be improved through the provision of more plug-ins and extensions, such as data distribution, load balancing, new data types, indexing and searching, etc. They could also make it easier to access data manually.

PostgreSQL is Open Source Project, it is never ending development process and maintenance. Since 1996 up to now already 20 Years, PostgreSQL has been borne as Open Source, while before it was an academic research. There are already some improvement actually, such as: Load-balancing can be achieved by Multi-master Replication or PostgresXL with real clustering model. Multi-master replication a.k.a Bi-Directional Replication is best implemented in data distribution topology.

There are many solution from that new features. It already a time to go to implement it on High Performance Transaction system, huge system implementation, mission critical system, most of the time, PostgreSQL is implemented in the financial and service industries, including banks, insurance, loan companies etc.

As an Object based Relational Database, there are many opportunity for expansion of PostgreSQL in many ways. We can create another data type, we can create another programming languages for functions. etc. There are limitless opportunity for expansion of PostgreSQL features, and it is already surpassed Oracle, in terms of Performance, Capability and Enterprise Features.

We've been using it since 2003, when it was v7.x

We have had no issues around the deployment.

Usually stability issues are caused by misconfiguration or misuse.

We've been able to scale it for our needs.

Since this is open source it doesn't have its own support. Therefore, my company provides support as a Maintenance Service Provider. We offer 24/7 support as well as the delivery of sophisticated deployment, tuning, consultation, and support of PostgreSQL.

It was straightforward.

We were helped in the implementation by the vendor. You should always let an expert do the implementation as if it is configured incorrectly it can have a big impact on performance.

I would recommend PostgreSQL to anyone who wants to save costs and deploy a reliable enterprise class database server.

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.

The graphical query plan analyzer in pgAdmin III tool is a very valuable feature. Fast bulk data load and extract feature using COPY is a very useful feature I have used.

Helped solve my problem to extract large amount of data in a specific order on a Greenplum application.

String manipulation functions can be improved. I could not find reverse string function and ended up writing my own. Similarly array functions like length of array etc where not available and we created our own.

I've used it for 4 years now.

PostgreSQL provides the perfect combination of freedom, reliability, stability, security, performance, power, and ease of use. Freedom because it is the only world-class RDBMS not owned by a company. Reliability because anyone looking among the tons of public bugs from other RDBMSs such as Oracle or DB2, and does a comparison with PostgreSQL bugs, will feel confident. PostgreSQL is secured by design, with their own firewall for host-based authentication. PostgreSQL has a superior optimizer, the performance is very good in heavily loaded environments, and it has unique features such as partial indexes and full text search support with GIN indexes. Regarding power, PostgreSQL is a best of breed RDBMS in terms of SQL capability, procedural languages (many of them), programming language and datatypes support (including JSON) and async LISTEN/NOTIFY. Finally, the ease of use or autonomy, is a very valuable factor; PostgreSQL have all the configuration in two single files (postgresql.conf and the "firewall" pg_hba.conf).

We have migrated some databases from Oracle to PostgreSQL lowering licensing fees and reducing the vendor lock-in, gaining sovereignty.

The are many items in my wish list - parallel access (in development), incremental backups, standard MERGE statement (there is a similar INSERT/ON CONFLICT DO), snapshot queries (SELECT AS OF TIMESTAMP), better monitoring stats views, a "trace" feature for a specified running backend, allow streaming replication for a standby from a previous major release in order to minimize downtime during upgrades (this could be difficult with physical standbys, maybe could be easier with logical replication). Of course, everybody needs to keep in mind that any wish list needs to point to the core features, because PostgreSQL is FOSS, and there are other ecosystems out there developing third party features. Here, my wish list for third party software factories is the HTTP->PL/pgSQL adapter, that will enable the development of an Enterprise Web Application Development Framework with just a database (like Oracle APEX).

I've used this solution for more than six years. I started using it in 2009.

Deployment is very easy in PostgreSQL.

Regarding stability, I never viewed runaway processes, nor needed to execute kill or use the Linux IPCRM command against PostgreSQL resources, unlike Oracle and DB2.

It is possible to scale-up (simply adding resources), on demand and without restrictions because PostgreSQL is free. Further, it is possible to realize read scalability with hot standbys.

Very good, based on the few opportunities where I have had to post a problem. I always got an answer quicker in the PostgreSQL forum than opening Oracle SRs or IBM APARs, and the resolutions were also more accurate.

I have more than 10 years of DBA experience, working with Oracle, DB2 and MySQL too. All of them have pluses and minuses, and I usually need to explain that nobody can claim "X is better to Y", at least with the universe limited to world-class RDBMS like PostgreSQL, Oracle, DB2 and MySQL. Of course, certain scenarios can mean that one RDBMS is better positioned than another to handle.

The learning curve is much friendlier with PostgreSQL than with Oracle or DB2. In fact, this could be a risk, because heavily loaded production environments usually needs DBA monitoring and intervention.

I did it in-house. The only advice is to read and learn from PostgreSQL documentation and related books or blogs. PostgreSQL is easy to start, but is a complex RDBMS with many screws to adjust.

There is no pricing/licensing at all. Of course, there are many companies offering PostgreSQL support at different costs and some specialized in several languages/countries.

Ask the community. I believe any committed PostgreSQL user will be happy to help and provide advice.

The spatial extension, PostGIS, is amazing and probably the gold standard. I also like the Key-Value column type and the JSON column type. Apart from this, it has all the other features you will need in an RDBMS and then some. It has a vibrant FOSS community with a great license and it has plenty of books and documentation

Rather than using Desktop GIS software we were able to carry out a lot of our spatial operations faster with larger datasets by moving the operations into PostgreSQL. We also save a ton of money on Oracle licenses. Finally, rather than having to give up my relational features, I can use the JSON data type and get everything I want.

They need to work towards making it work better in a cloud environment. Also, I would love to see them developm multi-master replication.

We have had no issues with the deployment.

There have been no performance issues.

It's been able to scale for our needs.

Get a good book so you can get exposed to all the great functionality in PostgreSQL. I would highly recommend looking at the postgresql.conf configuration settings when you are ready to go into production.

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.

PostgreSQL is a stable RDBMS. It's free, and supports standard SQL.

I have developed many portals and internet commercial sites with this RDBMS. It's easy and quick to publish portals and websites when you have this in production.

I believe that drivers must be better. For example, the .NET drivers could be more robust for the latest Entity Framework version.

I've been using it for two to three years.

There have been no performance issues.

It's been able to scale for our needs.

PostgreSQL is a community RDBMS. There are many articles, blogs, examples and information about its features on the internet.

The initial setup is easy because it's only a package. It can be setup either on the cloud or with hosting providers once it's installed.

I have used GoDaddy hosting, and Amazon EC2 with PostgreSQL. I don't have any problems.

My only cost is for the server that PostgreSQL is hosted on.

I've worked with MySQL, Firebird, etc. and, in my opinion, PostgreSQL is more scalable.

It is a good free RDBMS. It's stable, scalable and reliable.

Overall it is an excellent RDBMS and it is easy to use and administer. In PostgreSQL 9.5 the table inherent Foreign Data Wrappers(FDW) is available. This extension is available for most databases which makes building server federation very possible.

In 9.5 support for FDW was improved which means it is now possible to import a complete foreign schema. Foreign Table inheritance is now supported as well. They have also improved the Foreign Query optimization since v9.4. Lastly, It has low maintenance requirements so not much has to be done as far as DBA tasks go.

We were able to use the latest features described above to facilitate the integration of disperate data sources into our Postgres Data Warehouse.

• Improved support for parallel query execution
• Merge Joins
• Improved Handling of Materialized Views

I've been using it for years.

We have had no issues with the deployment.

There have been no performance issues. It's a very stable environment.

It's been able to scale for our needs and easy to extend when needed.

Although there is no tech support, it has a large user community who are always helping each other.

The last few versions work great out of the box without much config changes. Don't be afraid to try it.

• Hassle-free, low maintenance operation
• Free
• SQL compliance
• Slot-based streaming replication - live and purposely delayed are available
• Robustness
• Performance
• Low maintenance
• Decent Windows management GUI
• Cross-platform

It's improved security by allowing us to switch from an unsecure file-based database to a secure SQL database without license payments. Also, it provides us with multiple disaster recovery options with streaming replication.

It requires better management tools.

I've been using it for 12 years.

We have had no issues with the deployment.

It's been a stable product.

It's been deployed on >180 machines within the organization, ranging from Windows XP to Windows 2012 R2 and Ubuntu v12 to v16, and it's been stable.

Well worth the effort! I've been using it in my professional capacity without a single incident.

I had many problems on v8.3 when I needed to use SSL client certificate authentication but on version 8.4 my problem was resolved, I’m an information security specialist and my focus is it so all features about security for me is important and the security on PostgreSQL after 8.4 was good.

I can say that PostgreSQL increased the database possibilities within the company.

I have a dream that a database could import data safely and securely from other databases without errors and by using a GUI to help migrate the data. 

I've been using it for years.

We have had no issues with the deployment.

There have been no performance issues.

It's been able to scale for our needs.

In my last company, we had been using Access. We changed to PostgreSQL as we needed something more robust and usable. This was provided by PostgreSQL which at the time was the perfect solution for what we needed.

PostgreSQL is a perfect database to be used by small to mid-sized companies. Many years ago when I worked with medium companies I would have given it a 10/10 but as the database community has grown, it has decreased.

It allows people to use whatever multiple procedural language they are trained in, such as Java, Python, Pearl, or C and it is not limited to PL/SQL or PGSQL. Also, I love the PostGIS extension and I do not know of any other product like this.

I can integrate solutions quicker than with other RDBMS'. At the same time, I am able to keep an RDBMS' integrity, robustness, and High Availability which is the most important thing for all my production environments.

It is lacking some GUI admin tools and it would be nice if more could be developed by the community.

I've been using it for years.

We have had no issues with the deployment.

There have been no performance issues.

It's been able to scale for our needs.

It's the best in my opinion because have now found what I need to enable me to quickly deploy into my production environment. Go to a professional and ask for your needs, maybe you will surprise with a variety of solutions that you never thought existed.

• Very good indexing solutions, especially for arrays and text search on large quantities.
• Very good behavior on large databases (>800GB) and large tables.
• Datatypes - support for vectors, XML, JSON, UUID and the functions and operators for them are very useful.
• Programming languages - I deeply appreciate the extensibility of the server to allow more than one language for scripting functions. We mostly use PL/SQL, but recently I've tried PL/v8 and was astonishing to see that it works.
• Execute with Query Parameters is a big plus for us as there are no type conversions needed to run dynamic queries reducing the run time by approximately 25%
• There is a huge amount of community interest in developing and supporting the product.

All of our BI needs are implemented using PostgreSQL functions. Our tools are designed in such a way that the BI is implemented as much as possible through our database. We need a lot of flexibility to extend the BI logic on a specific installation.

Synchronous replication is needed, and although I have only searched the web for a couple of hours the only solutions I could find were at the application level of the database.

XML and JSON manipulation functions need to be improved as for some applications we need to add new elements to these "structures". To do this with JSON I currently use a PL/v8 extension.

We have had no issues with the deployment.

There have been no performance issues.

It's been able to scale for our needs.

Try it out! Sometimes, due to the high degree of configurability and extensibility, you might see some issues arise, but it's not that difficult to figure out what's happening. You will definitely be amazed by the SQL features and extensibility.

PostgreSQL has excellent support for many programming languages. We've been able to integrate it with Java, PHP, Perl and .NET without any issues. 

Replication is also working pretty good in a master to read only replica setup in AWS. 

We've been able to cut costs on databases over our previous solution with Microsoft SQL Server and migrate many applications into Amazon web services. Performance has been decent. 

By far the biggest limitations are in replication support. A native master to master replication option would make things much easier as we're in need of an easier method to load balance traffic with Spring Data.  

PostgreSQL is slower than MySQL with insert performance. While using COPY can make an application fast, we often use ORMs which cannot benefit from this. 

9.4 seemed to have some regressions with the query planner and multi table joins are slower than in previous versions. 

I've been using PostgreSQL for 5 years.

Finding the right configuration to balance performance and connections was a little challenging in our setup. 

We've encountered some CPU bound scalability issues with multi table joins (3-4) and the query planner seems to ignore indexes at times. 

Initially applications at my current employer used Microsoft SQL Server. The cost for licensing/maintaining windows systems was more than we liked. PostgreSQL has offered similar performance for our workloads with lower cost. 

It has the same features as paid-for databases such as Oracle and SyBase.

It's saved us money as it's free.

Eliminate the transaction wraparound possibility. If transaction wraparound occurs it can be a major problem.

I've used it for two years.

There were no issues deploying it for us.

We've experienced no issues with performance.

There have been no issues scaling it for our needs.

There is none available as it's a community driven solution.

It's simple to get it up and running.

We did it in-house.

We tested a big portion of our online API product using SoapUI and it was very fast and efficient.

Use this product for simple needs if you do not have PostgreSQL expertise. If you have PostgreSQL expertise you can run your business off PostgreSQL.

It has allowed us to run a Scada database, which reads data every 2 minutes. It does it in a very smooth way.

I would like to have better support for real-time applications.

I've been using it for three years.

No at the time. Our application fits very well.

No at the time. Our application fits very well.

No at the time. Our application fits very well.

I have used online free help.

MySQL but not in the same scale.

We implemented it in-house.

Analyze very carefully the hardware requirements.

There are many valuable features, but the most valuable to me are Windows functions, Python scripting, and the fact it has a good PGSQL language.

It provides standardization on the database and related skills.

Parallelization and some connection to analytics is needed.

We had no deployment issues.

The product is quite stable.

It has the ability to scale up into products like Redshift.

The online manual is superb.

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 is a superb database. What keeps it from being 10/10 is a lack of analytics specific optimizations.

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.

• Stability
• Standard SQL for ease of development with pre-existing knowledge

Postgres is for our systems a very solid database, easy to use in development and easy also to manage in production environment, and that's valuable because in the end it cuts a lot of costs (also during the upgrading processes).

The Postgres team is already doing an amazing job in putting in features to ease the life of developers and sys admins, such as JSON support and database replication.

A feature that is still a work in progress and it would be nice to have would be native master-master replication, we don't have a need for it right now but it's something that should be addressed in the future.

I've used it for five years.

There have been no issues with the deployment.

We have had no stability issues.

It has been able to scale it for our needs.

I've had no need to use any.

I've had no need to use any.

I used MySQL and Oracle previously, PostgreSQL is open source and fully ACID and SQL standard

It was easy.

We deployed it in-house.

It's a great database engine that is easy to use, powerful, and scalable.

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.

It's reliability is key.

It allows us to deploy test functionality on a very simple normal computer and not on a server.

I'd like to have NoSQL available in this version. It is available in the latest one.

I've been using it for six years.

We had no issues with the deployment.

I've had no stability issues.

It scaled for our needs.

8/10

I switched as I needed to increase the volume of data.

It was a bit complex to setup, although I think this was due to ignorance on the project.

We did it in-house, but only to test different databases.

Use it, to change the default database, it's a good option.

• Flexible stored procedures and external functions
• WITH clauses
• Partitioning
• Large open-source extensions, modules and software helpers eco-system

The documentation is very well written and detailed, it helps to implement the right features for your needs in a timely manner.

Parallel processing of queries.

I've used it for 12 years.

There's been no issues deploying it.

The product always worked as described.

We've had no issues scaling it.

There is no tech support, however there is a lot of information available in forums or sites like serverfault.com.

I used MySQL. PostgreSQL syntax is much clearer and consistent, and its stored procedures are powerful and fast. The documentation is also much better and of more help.

On Debian, the provided packages are very easy to install and provide automatic updates. On Mac OS X, EnterpriseDB provides packages that work very well but as not as well integrated than in Debian.

I implemented in-house. PostgreSQL databases needs some maintenance but that can be easily automated by a skilled administrator.

PostgreSQL is free and open source.

Read the documentation.

The h-stores are very powerful for handling collections of key-value pairs. The query syntax and functions are well documented and easy to use.

PostgreSQL is a powerful and open source database, which is central all data processing.

We'd like to be able to start using JSON objects for easy code representation. This feature is available in v10.4.

I've been using it for eight years.

We've had no issues with the deployment.

There have been no stability issues.

It's been able to scale for our needs.

I use online documentation, which met my needs.

We were using version 8 before, and also an earlier Oracle instance. We chose the product because it is powerful, well documented, and open source.

I did not set up the actual installation. I did set up the schema, tables, foreign keys, etc. That was straightforward in that it was well documented.

In house. You do need someone that knows PostgreSQL or that can spend time learning about the product.

It's open source. ROI is a matter of time.

The challenge with this product would be finding the IT resource that can implement the product.

Many supported features out of box like fulltext search, partitioning, easy replication - slony, pgpool-II and streaming wal and additional features such as JSON, XML, arrays in columns, and many extensions for it as PostGIS.

I'm working as architect for a custom software development company and we are using Microsoft SQL Server, Oracle DB and PostgreSQL as our main databases, in recent years Postgre is offering more and more useful features which we can use. For its open source model and very good documentation is very easy to optimize queries within bigger databases (100GB). Also its free and its lowering price of our solution so we can (and we are) address smaller customer.

The biggest issue that we are having is upgrading and moving databases between servers and versions. Restoring database is slow with pg_restore because indexes are need to be rebuilt. What I'm missing is a query profiler similar to what is in Microsoft SQL Server. PgAdmin should also be easier to use for beginner users.

We have been using PostgreSQL for about 10 years.

After many years of usage we are not experiencing any unusual problems with PostgreSQL.

After many years of usage we are not experiencing any unusual problems with PostgreSQL.

After many years of usage we are not experiencing any unusual problems with PostgreSQL.

We are not using customer service or technical support.

We are not using customer service or technical support.

We are using PostgreSQL for new installations and new versions of our solutions where it's possible, and the customer does not require a specific SQL server. Nowadays it's covering all of our needs.

Depends, for basic setup, it is quite straightforward but for more advanced features (like WAL streaming and hash indexes) it is a bit harder during the first few days because of a lack of documentation and experience.

We did it in-house.

There are no license fees for getting PostgreSQL and we don't yet have experience with paid support such as from EnterpriseDB, but we never needed it.

Your first investment is only in people working with PostgreSQL, and it is the same as with Microsoft SQL Server, but less than with Oracle. Hardware costs are lower for PostgreSQL and Oracle but those are not significant.

My advice is to read documentation thoroughly and don't be afraid to look into source code. A great source is https://momjian.us/main/presentations/overview.html

Speed and price, it’s fast and reliable, and free.

Due to budget restraints procuring software is always an issue, and mainly production systems are well maintained. However development systems are not usually so well off. As PostgreSQL is free, this enables us to develop applications without having to think about budgets, and give us greater flexibility. There is still reluctance by business to accept free ‘Open Source’ software, but proof of concept development can be achieved at no to low cost.

Simplicity in design and improvement with programming languages like PHP.

I've used it for four years.

In development it’s super sensitive with comma, quotations, and letter cases. It should not be. If we use uppercase sometimes it works and sometime not, and its need to be single quote sometimes but sometimes double quote.

There have been no issues with the stability.

We've had no issues with scaling it.

I've never used customer services, but it needs a better documentation.

We use both MySQL & PostgreSQL, some applications have better compatibility or built in tools, this decides which database we use.

It's straightforward.

So far we have not had any issues with this database are we are using this in development and production systems.

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.

HStore is a data type in PostgreSQL database that gives the flexibility for storing sets of key/value pairs which is quite an awesome feature.

Slow count. As the number of rows exceed a couple million, the count query and queries which get to the depth of the data (like FTS) start taking too much time even with all the right indexes in place.

I've used it for two and a half years.

We use RDS Multi - AZ deployment which takes care of it all for us.

We've had no stability issues.

There have been no issues with scalability.

I've never had an issue with the product, and therefore never had to reach out.

We tried RethinkDB a couple of years back, and it was unstable at that time. Also, MySQL didn't have a JSON type back then. We switched to PostgreSQL and never looked back.

I do remember facing problems with the initial setup, but the overall documentation and SO answers has increased since then. New users face much less problem now. But there is still scope for improvement here.

I'd recommend reading Greg Smith's PostgreSQL High Performance.

The reason why I started with PostgreSQL database was the (geo)spatial support. GIS software, such as Quantum GIS (QGIS) or PostGIS, is a good example of where you are able to use this feature. Nowadays, the solution is on a competitive level to other commercial software solutions, especially for small companies.

PostgreSQL (geo)spatial support is stable, and you can add, remove, and edit all standardized GIS features. Thanks to projects such as EDB, Bitnami etc., PostgreSQL can be used by people on pure user level, without deep knowledge of OS administration, programming.

There is room to improve some user friendly properties such as input and output tools, some people may find interesting to implement MERGE as a SQL command. I am looking forward to trying UPSERT and would like to test some analytic functions definitely.

I've been using v9.4 for a half year. I also have experience with previous versions of PostgreSQL. Currently we have PostgreSQL 9.4.7 on Fedora Server 23 and PostgreSQL 9.4.5 packaged by EnterpriseDB (EDB) on Windows 10 Pro.

I had trouble with the reinstallation of EDB. If I have a previous version on my Windows PC, I have to take some steps to clean the registries and folders, then everything is OK.

If you are interested in you can find answers for troubleshooting. Many companies, I have mentioned above, are there for service and support. I didn’t find any big bug in the latest stable release over the last few months.

If you are interested in you can find answers for troubleshooting. Many companies, I have mentioned above, are there for service and support. I didn’t find any big bug in the latest stable release over the last few months.

I recommend Linux installation, but it is also possible to use Windows. With PostgreSQL you don't have to pay much money which is a good advantage. You have to take into account that you will spent some time finding out how to implement something or what is the right tool you have to use.

PostgreSQL is a long-lasting investment for people who like computers and don’t want to spent much money for database layer implementation.

• Easy to use
• Vastl documentation
• Tough product

We used it from scratch of the organization. It helped a lot since we could improve our hardware, and we upgraded the Heroku plan as we grew.

It could be easier to perform some fragmentation in the database. It's possible, but still a hard job.

I've used it for about three years. Currently we use PostgreSQL provided by Heroku and AWS. On Heroku we use a premium 6 plan with v9.4, and on AWS RDS the version is also 9.4.

The biggest problem we found so far is not in the product exactly, it's in the service provided by Heroku. Heroku locks us in hiding some features that would make a lot easier moving to another PostgreSQL provider.

We have had no issues with the stability.

We have had no issues scaling it for our needs.

7/10

7/10

I used other solutions in other companies I've worked for before. When I arrived at my current company they were already using PostgreSQL.

I wasn't involved in the setup as it was already in place when I joined.

We implemented it through a vendor as using this kind of service is easy and fast to get started. You don't need experts, and you can keep concentrating on your core business. However, when you grow the costs grow, and as in our case, it might be hard to leave the vendor.

It does what it's supposed to do, as simple as that. We don't regret any choosing this solution.

JSON data support is most valuable to me as it saves design and maintenance time. It is a very safe and stable solution.

We are spending less time parsing API response and more time exploring data. We spend time understanding APIs and how to interact with them, If we can load responses directly to the database that saves many man hours for a project.

A better export facility which is GUI friendly would be an improvement. Also if we could export data from grid that would have been helpful.I have used HeidiSQL for MySQL which is very user friendly, pgAdmin III is not that helpful when it comes to different features we need to use like export,filtering and connections.

I've been using it for one year and am still exploring it.

We had no deployment issues.

We had no issues with the stability.

We had no issues scaling it.

I have worked with MySQL, Microsoft SQL, db2, and Oracle. We chose PostgreSQL for its JSON support as our APIs are sending JSON responses and PostgreSQL is like home for JSON. Choosing it has helped our cloud computing requirements a lot.

On Windows it's straightforward, but on Ubuntu, it was a bit complex when it came to database and tablespace division through PSQL.

We did it in-house.

If you are thinking of using PostgreSQL, all database names, table names and column names should be in small letters. PostgreSQL requires every capital letter to be quoted which makes life difficult for developer.

• Stability
• Performance
• Ease of administration

It is a world class, performer, a scalable database that is free and open source.

At the fringes, you can have locking problems that can cause unacceptable pause, but that's really a factor of database design, and the limitations of relational databases as a technology than a particular issue with PostgreSQL

I've been using different versions of PostgreSQL for the past eight years.

There was other a foreseen issues with pushing it to the edge.

It's a very stable product.

It's easily scalable.

The amount of community support for the solution is good.

We've got experience with a number of RDBMS, but PostgreSQL has always stuck out to be the most economical and sensible product. That being said, we do have instances of Maria, and various NoSQL's floating around.

We did it in-house.

It is an open source solution and that is a database engine very powerful. Besides it is highly configurable. I prefer PostgreSQL over MySQL or MariaDB because you can create several databases with many schemas and create roles like owners, and not only grants over tables, or procedures. On the other hand its very easy and intuitive to administrate the connections by hosts, databases, and roles.

PostgreSQL is a powerful dateserver although not like Oracle. So we can make many developments in a cheaper way with high availability. Besides, its very useful tool for debugging with a soft learning curve.

It needs to be able to cluster. We have implemented the high availability with a master-slave mode and one host in only read mode. This is the worst feature of this product and the quality sign of Oracle.

I have been using PostgreSQL server for three years.

The upgrade from v8.4 to v9.3 was a little hard, but this was executed finally well.

We had no issues with the stability.

We've had no issues with scaling it for our needs.

I've not had to contact them.

I use MySQL, MariaDB, and Oracle. I chose PostgreSQL or others depending of the project. For Java implementations I prefer PostgreSQL, and for PHP development, I prefer MySQL or MariaDB,

In my opinion the initial setup is easier than MySQL because it is more intuitive, but you must to edit a couple of config files, and become more aware of the entire infrastructure.

It's open source code, so you get it for free and need to contribute to debugging errors and improving the code.

Be patient! Like most open source tools, this requires commitment and a little knowledge.

* pg_hba.conf

* A fragment from postgresql.conf

* How to access to database-server using psql client, and create a database

Create a user/role and be owner for a database. We can list all databases with "\l".

The product is free, which is a huge benefit. There are options to create clusters and maintenance on the databases is easy and fast. The management studio with product is create and intuitive.

We used this product for applications which require a database. Since MS SQL Express has limitations and regular MS SQL requires pricey licensing, PostgreSQL was an easy choice. The deployment is quick and easy and works with very little configuration, if any at all.

The commands for PostgreSQL work, but are behind the curve compared to Microsoft SQL and MySQL. Adding additional functionality to be move comparative to Microsoft SQL would be a nice to have. For experienced users needing to make configuration changes, it is straightforward, but for users who are new to PostgreSQL they need some help working within the config files, a GUI for config may help with this.

We've been using it for four years.

I've never had any issues performing multiple deployment.

There have been no issues with the stability.

We have had no issues scaling it.

I have never had to contact support, but the documentation they have is very good and extremely detailed.

We use Microsoft SQL (all versions), MySQL, PostgreSQL, SQLite, etc. We use PostgreSQL when the application supports it and where it makes more economic sense to use it.

Following the setup documentation was extremely straightforward and simple to follow. We have no issues with the install, config or operation of the application.

We did an in-house implementation for PostgreSQL. The documentation made it easy to do and was very simple to follow.

PostgreSQL is free to use.

Ensure its a good fit for the application you are using and integration you may have planned. Review all documentation prior to moving forward and always test the new versions before just cutting over.

By far indexes is the most useful and robust feature. Also, the query optimization engine is simply great. It is very complete, clear and useful documentation, forums and diverse information channels.

Most of the enterprise I have worked has been startups and small to medium software industry and data analysis. One of the most improvement it is not in the mean time but in the middle to long time. At first sight it seems to an overkill implement a product as PostgreSql for small projects; even managers and investors tend to put some resistance to it. Then, as soon as projects start scaling and data set increase in size, concurrency, consistency and data types, is were you think PostgreSQL was one of your "hit" on the project design, time give you lot of credits.

I think that data types that decrease the breach against NoSql Databases will be the next steps. I am not talking about changing to a pure NoSql DB but to some features that will face the big change in data analysis and maintenance that that DB are facing nowadays. Also tools for distributed replication and clusters should be more researched and improved; anyway nowadays there is some of them.

I have been using PostgreSql since University where I teached students some DB theory concepts. The course was focused on indexing and benchmarking. Also I use it on software industry, as a DB manager, designer and operator; common tools were PL/pgSQl, indexing and tuning; using about 3.0M per month DB tuples inserted and about 500tps on peak points. Finally I use it on personal projects, for small data sets (~1.000).

We have had no issues with the deployment.

I have faced just a few issues working with PostgreSql, one of them was specifically on Hash Index (see as example http://www.postgresql.org/docs/9.2/static/sql-createindex.html.

We have had no issues scaling it for our needs.

Most of the great value of PostgreSQL is the variety of technical support you can find Consulting, lots of forums, and big communities who have been using and documenting PostgreSQL for a long time. I have never faced a problem or question that couldn't be solved using these channels.

I have worked with MySQL and Oracle solutions. Against MySQL, performance is the big difference. PostgreSQL is far more robust and mature than MySQL, especially when you think about keys and indexes. Against other databases, such as Oracle, the easy installation steps of PostgreSQL is the best difference for me.

I have faced a few issues while installing it and configuring it; most of them related to incompatibility while using old Ubuntu Linux versions.

I have always implemented it in-house, and as all solutions for everything on vast areas, is highly recommended read guides on how to install it.

ROI is by far fair enough for startups and enterprise projects that are expecting a big grow in the mean time.

PostgreSQL license is a fair enough for small to medium size business solutions.

Just read the comparisons between different database engines, and read some documentation so you can exploit most of the powerful tools and functions it has.

• Security
• HA and DR
• Performance
• Maintenance

I worked as a consultant/trainer. I have a few installations of Dev/Test in my VMs, and I don't have anything in the production installation in our organization.

It's not very user friendly, as it is open source and has no immediate support. You can download the Enterprise version of Postgres that is a GUI installation and also have a support contract.

I've been using it for five to six years. I did the PostgreSQL DBA’s training and led the implementation and data migration projects.

We also use the EDB Postgres Plus Advance Server v9.3 (EnterpriseDB). We use it to evaluate the Database migration from Oracle to Postgres. The data level migration was successful but for objects, and at the security level, you have to fix issues manually.

We've had no issues but setting up the replication, security, and login is different from other databases.

We've had no issues with the stability.

There have been no issues with scaling it for our needs.

As mentioned earlier, there's no support contract for open source but with EDB (EnterpriseDB) you have the open to purchase the support contract. I don’t have any experience with EnterpriseDB support.

It's straightforward, as it's an open source product.

We did it in-house.

As it's open source the ROI is quick.

The core product is free but you have to pay for third-party utilities / plugins and support.

I have evaluated MySQL and Ingres previously and then PostgreSQL. My personal choice is PostgreSQL. I also worked on a migration project from Ingres to Oracle.

• Positive - 100% free as it's open source
• Negative - it's hard to find expertise

If you are planning to migrate an existing environment, please go through with the full UAT cycle at data, connectivity, objects and apps level.

The most valuable features are a good feature set, understandable, and good tuning features. It is, also in our experience, the best open source GIS enabled database, with good support from other open-source tools.

The product has easy installation procedures for the OSes we are working with and gives also a good possibility to tune the database for the given usage.

The database is used to set-up customers projects and is our standard database which we use.

One of the features it needs is a tighter integration with business intelligence software, so that the optimisation of the requests can be handled natively in the database. These features are on the roadmap, and are already partially released in the latest version.

We have been using this database for about 18 years.

We have had no issues with the implementation. Most of the issues we have encountered in external installation where due to misconfiguration.

There have been no issues with the stability. Most of the issues we have encountered in external installation where due to misconfiguration.

We had no issues scaling it for our needs. Most of the issues we have encountered in external installation where due to misconfiguration.

We have up until now not needed additional customer or technical support, these can be purchased by supporting companies.

We have been using Oracle software, and in some cases MS SQL server. The price difference between the used products and PostgreSQL was one of the issues. The second was the ease of installation and the availability on different platforms.

The initial setup is easy to perform, but the tuning is a bit more complex. The installation support on Linux flavours is excellent and has native installation packages.

Implementation and installation was carried out in house.

The pricing of the database is open-source and our investment in the product is based on training.

It can handle complex SQL queries.

It has helped to cut costs because it's open source.

It needs better support for JSON and web services.

I've been using it for 13 years.

We had no deployment issues.

We've had no stability issues.

There have been no issues scaling it for our needs.

It's open source, so there's no technical support available.

It was simple to setup.

We implemented it with our in-house team.

There was an immediate return-on-investment of 100%.

We also looked at MySQL and other databases including open source, standards, compliance, and enterprise features.

We have no regrets and are satisfied with it. I would advise you to go ahead and implement it.

It supports full text search, and windows functions.

All our data is stored in PostgreSQL, and we use a BI solution on top to gather all the important metrics to our business, so the whole company has a clear picture of what is going on.

It lacks the ability to distribute queries across multiple installations out of the box.

I've used it for seven years.

No issues encountered.

I've never experienced any data loss.

No issues encountered, even when querying through third-party applications.

I've never had to deal with customer service.

The support in the community is excellent, the documentation is great, and questions submitted to the mailing list are quickly answered. The IRC support is also excellent.

I used MySQL, but I needed support for full text search. PostgreSQL adds this, and also many more advanced SQL functions.

Setup was very easy on all platforms that I use - Linux, Mac OSX, and Windows. It is a simple walk-through installation.

It was done in-house.

It's a free solution, and we use it as a data store, it's all return.

PostgreSQL is free software. The only cost of setup was a few developer hours, and with it being stable, we don't have any day-to-day costs.

• MySQL
• Microsoft SQL Server

PostgreSQL is one of the most stable data sources out there, and it offers you the most advance and modern functions on SQL so you can do more with less.

6 years

Authentication config could be made easier.

It's very stable.

The use of extensions for integration with different databases is valuable.

Our organization has MySQL, Oracle, PostgreSQL and flat files in our processes, and the use of extensions has facilitated the integration between these processes. Also, it's only 7-8/10 when comparing it to an Oracle database.

The use of XQuery besides XPath into PostgreSQL. It would also be nice for them to add some backup features similar to the one that Oracle Recovery Manager has. Also, a tool to query archive files would be a nice addition, and being able to change the execution plan through hints like we do in Oracle. There are some more but these would be my favorite ones.

I've got six years experience with PostgreSQL, and 18 with Oracle.

No issues encountered.

No issues encountered.

No issues encountered.

I'd rate it as 10/10 as an open source product with an active community.

I'd say it's good.

We initially only used an Oracle database, but we decided to add PostgreSQL as an option because of its similarity to Oracle. Also, it's free and is the best open source database.

It is simple, especially when you know the main components of a database.

We implemented it in-house.

We didn't have any setup costs because it is free.

• MySQL
• SQL Server
• Sedna XML

I'd say go for it. It is stable, and easy to use but you should get an understanding of it to implement backup strategy.

It allows us to have an alternative solution to licensed DB's.

It requires enterprise integration improvements from the security, and audit perspective (AD integration etc.). Also, integration into existing BI tools is not present.

I've used it for three years.

They provide a high level of technical support.

We switched due to a common OS integration strategy.

We had an RFP process to evaluate between similar product categories.