PostgreSQL Reviews

• 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