PostgreSQL Reviews

I have been using PostgreSQL for the last two years.

I am using PostgreSQL in two projects. The recent one is in the financial domain where the SQL database is PostgreSQL and we are performing a significant amount of CRUD operations.

We have implemented RAG in our agentic AI application. For RAG we are using PG vector. For our day-to-day SQL communication and all CRUD operations, we maintain user data and all transactions because my product is in the financial domain. PostgreSQL is working very well, and I have never seen any performance issue.

Our domain is financial, so we definitely need to maintain transactions, maintain state, and ensure persistence. We are using a SQL database and from SQL we are using PostgreSQL. The first reason is that PostgreSQL is capable enough to handle large transactions of data. Second, we are using a pooling mechanism where we have put some open connections within a buffer for handling high-scale data and use that connection to communicate with PostgreSQL and retrieve the data.

Initially, we decided to go with a different database. When we were doing more than 50,000 transactions in a minute with that database, we were getting a lot of latency issues. Threads got blocked and got abruptly closed unwantedly. We decided to move to PostgreSQL after doing extensive research. Now, we are doing the same level of transactions in PostgreSQL, around 100,000 transactions, and we are getting good throughput with no latency.

If a customer pays for something and something goes wrong where the amount gets debited but does not reflect on the e-commerce website, the customer is going to raise a ticket. While raising a ticket, it hits our customer service team. The customer service team has to investigate the issue and they are dependent on our engineering team. There is a whole cycle which is included for a single transaction failure. Before we were using PostgreSQL, we had to invest a lot of time into customer service. We had to ramp up our customer service resources, and overall, a lot of bandwidth was required. Now there are very few transactions that fail. Overall, we have a very small customer service team and a good engineering team with no overburden or bandwidth issues. This is definitely giving positive results on product efficiency and product cost.

The best feature is performance, because of which I decided on PostgreSQL. I have also enabled the PG vector plugin on top of PostgreSQL. I have the opportunity to use two different features and two different flavors in a single product, which is the best thing about PostgreSQL.

Initially, we had some hiccups around the performance part, but later we did indexing in PostgreSQL and now it is working very well. Even when we are doing 100,000 transactions in a day, PostgreSQL is working excellently.

The interface is another best feature. If I need to do any query, I simply install the plugin on my local, which is pgAdmin. Through pgAdmin, I am able to communicate with PostgreSQL and execute all my SQL queries. I am getting a better UI with PostgreSQL as the backend, which is also one of the best options.

PG vector is also very strong from PostgreSQL where I have implemented RAG and on a daily basis, I inject thousands of pages of PDF. More than 100 PDFs are coming into my system and one PDF is around 1,000 pages. We are injecting them into PostgreSQL and converting them into dimensions and inserting them into PG vector. The level of transactions we are doing on a daily basis is substantial, and we are getting very good throughput and low latency from PostgreSQL.

When we were doing more than 50,000 transactions in a minute with the previous database, we were getting a lot of latency issues with threads getting blocked and abruptly closed unwantedly. After doing extensive research, we decided to move to PostgreSQL. Now, we are doing around 100,000 transactions in PostgreSQL and we are getting good throughput with no latency.

The only thing for PG vector is if the dimension limit could be increased. Currently, the dimension limit is around 1,000 to 1,052. If I need to increase the dimension to 3,000 or 5,000, that option should be available.

The UI is also an option if I could get something similar to Snowflake, which has a cloud-type database with their own UI and everything. I understand it is a SaaS product. I am not sure if in the future PostgreSQL will come with the same approach. This is one of my recommendations.

I have never seen any performance issue in PostgreSQL.

Until now, we have not faced any issues.

Initially, we decided to go with a different database. When we were doing more than 50,000 transactions in a minute with that database, we were getting a lot of latency issues with threads getting blocked and getting abruptly closed unwantedly. We decided to move to PostgreSQL after doing extensive research. Now, we are doing the same level of transactions in PostgreSQL, around 100,000 transactions, and we are getting good throughput with no latency.

We have auto-scalability enabled. By default, based on the demand, it automatically scales.

If a customer pays for something and something goes wrong where the amount gets debited but does not reflect on the e-commerce website, the customer is going to raise a ticket. While raising a ticket, it hits our customer service team. The customer service team has their own processes to investigate the issue. They are dependent on our engineering team. There is a whole cycle which is included for a single transaction failure.

Before we were using PostgreSQL, we had to invest a lot of time into customer service and ramp up our customer service resources, and overall, a lot of bandwidth was required. Now there are very few transactions that fail. Overall, we have a very small customer service team and a good engineering team with no overburden or bandwidth issues. This is definitely giving positive results on product efficiency and product cost.

Previously, I used Snowflake because it is a proper cloud solution and I thought it might be a better opportunity. The problem is that Snowflake is very costly. We switched to PostgreSQL because PostgreSQL is cheaper than Snowflake. Second, as a total cloud-based solution, Snowflake has shown performance issues many times while PostgreSQL has not shown any performance issue.

We have auto-scalability enabled. By default, based on the demand, it automatically scales.

I purchased from the marketplace, so licensing and pricing cost is acceptable. To be honest, there is a separate team who handles the cost of licensing everything. I have admin access on Azure and I took PostgreSQL from the Azure Marketplace. From the cost perspective, I am not aware of the exact cost, but right now it is within our budget. Even with doing 100,000 transactions right now within PostgreSQL, we are happy with PostgreSQL and not seeing that it is expensive or going out of budget.

I evaluated only Snowflake.

If you need to do a lot of transactions on a daily basis and your traffic is very high for your products on a day-to-day basis, it is better to go with PostgreSQL rather than going with any independent SaaS solution because SaaS solutions have their own cost metrics and their own trade-offs. PostgreSQL is a very old and tested SQL database used in many products. I think it is better to use PostgreSQL. I would rate this product an 8 out of 10.

I have been using PostgreSQL in many applications, such as for user authentication and account management, for creating user profiles, login credentials, and session and token information.

I built a real-time collaborative drawing and chat application using Next.js, Node.js, and Prisma with PostgreSQL as the primary database. PostgreSQL was used to store structured relational data, such as user tables, room tables, messages tables, and shapes tables. For room management, the backend generates a random slug, and room details are stored in PostgreSQL. For chat history and shape persistence, I have been using PostgreSQL to store shape data as JSON, allowing reloading of drawings when a user rejoins a room and persisting collaborative elements.

PostgreSQL fully supports ACID transactions, including atomicity, consistency, isolation, and durability, which are some of the best features it offers in my experience. It also supports multiple index types, such as B-tree, Gin, Gist, and BRIN, and provides JSON and JSONB support, which is used to query semi-structured data.

PostgreSQL uses Multi-Version Concurrency Control, which allows multiple users to read and write simultaneously. For extensibility, PostgreSQL allows extensions such as PostGIS and pg_trgm, which are truly useful.

PostgreSQL improves reliability, performance, and scalability in production. Since it is ACID compliant, it ensures that database transactions are safe and consistent, preventing partial data updates, maintaining data integrity, and allowing multiple users to read or write data simultaneously using MVCC. Features such as foreign keys, constraints, and triggers impact data consistency by preventing invalid data. It supports read replicas, partitioning, and horizontal scaling for scalability.

PostgreSQL has been very stable in my experience, handling concurrent requests reliably while maintaining data consistency with ACID transactions and accommodating concurrent users with strong data integrity, making it mature and widely used in production systems.

Using PostgreSQL with Prisma allows faster development because schema migrations are automated and type-safe queries reduce the time I spend fixing database bugs, allowing me to focus more on building features while improving collaboration between developers due to a well-defined relational schema. Migration tools keep everyone's database schema synchronized, which allows multiple developers to work on backend features without conflicts.

It has a rich feature set, supporting advanced features such as window functions, common table expressions (CTEs), and full-text search, with the flexibility of supporting both JSON and relational data, meaning it can behave as both a relational database and a document database. Extensibility allows PostgreSQL to add new capabilities while maintaining a strong ecosystem that integrates easily with modern backend stacks such as Node.js, Docker, and Prisma.

Performance and scalability are areas where PostgreSQL can be improved. Query optimization improves slow queries by using proper indexes, avoiding unnecessary joins, and using EXPLAIN ANALYZE to inspect query plans. Proper indexing strategies such as adding indexes for frequently queried columns enable faster searching and filtering. PostgreSQL can slow down if too many connections are open, so it should use tools such as pgBouncer and implement table partitioning for large datasets.

Adding caching with Redis for frequently accessed data reduces database load and provides faster API responses.

I have been using PostgreSQL for the past three years.

PostgreSQL is an open-source solution, so support is mainly provided through community resources and commercial providers, with a very strong global community backing it up.

If PostgreSQL is hosted on cloud services such as Amazon RDS or Google Cloud SQL, the support is handled by the cloud provider, who provides automated backups, monitoring, infrastructure management, and technical support tickets.

I have been using MySQL, which was a very popular relational database for web applications and CMS platforms, and I switched to PostgreSQL because it has more advanced features such as JSONB, full-text search, and extensibility. I have also worked with MongoDB, which is a NoSQL document database.

I moved from MongoDB to PostgreSQL because when strong relational data integrity and complex joins are required, PostgreSQL works better than MongoDB.

I have used Prisma to connect to PostgreSQL because it provides type-safe database queries.

PostgreSQL is designed to handle large-scale applications. For vertical scalability, it can scale by increasing the resources of a single server, such as more CPU and more RAM, while also supporting horizontal scaling across multiple servers.

For using PostgreSQL, I would definitely recommend it to modern developers who are keen on developing and working with databases, advising them to design the database schema carefully and plan tables. I would rate this product an 8 out of 10.

We use it when we have large OLAP workloads and data rates that normal SQL can't replicate across all our systems – unstructured data where we can use code for everything. We use it with unstructured data.

We usually process data in batches, pushing the data to our data pack daily. So, PostgreSQL has handled high-volume transactions for us.

Our data security primarily includes encrypting our databases. We also use field certificates, and all data is replicated in an encrypted format.

We primarily use normal SQL queries. With a SELECT query, we consume the data and then push it forward.

One of the most valuable features is real-time data capture; it optimizes database performance. I think using real-time data capture reduces job running time and the amount of data sent at once with batch loads. Replicating the same data daily isn't optimal, so real-time reception improves application performance and reduces latency.

Sometimes, the views create problems. If you don't have the view, sometimes what happens is you need to have the drivers properly set up for PostgreSQL. Mainly, I think issues occur when applying patches to views; other than that, there aren’t many significant issues. 

I have been using it for five years now. 

It is a pretty stable product. 

There are 500 to 600 end users in my company. 

The customer service and support are okay because we have to wait for them to reply. It's not like we can dial the number and connect immediately. We have to schedule a meeting, and then they will come online.

Neutral

I used MySQL. 

If you have big data or unstructured columnar data, you should go with PostgreSQL. For structured data, MySQL is the best option.

The initial setup requires some effort. 

The time needed for deployment (install and configuring) four to five days are required. 

24/7 support roles are there.

If you have big data or unstructured data, go with PostgreSQL. If you have a smaller amount of structured data, SQL Server offers very good performance.

Overall, I would rate the solution a seven out of ten. 

Use cases include querying data warehouses and databases to fetch data for clients already working on PostgreSQL. 

We also use Postgres for building reports.

It's a transactional database, so we use Postgres for most of our reporting. That's where it's helping.

The query speed is fast, and the transaction processes are fast.

The replication capability is good.

Sometimes, it becomes slow because of the network. So, there is room for improvement in performance. 

Also, one more issue is that Postgres SQL doesn't allow multiple users to access locked tables at a time. I would like to see this feature in future releases. 

I have been using it for two years. 

I would rate the stability a seven out of ten. 

Sometimes it becomes slow when multiple users are logging into the same database. And also, when running pipelines, it can take time for the pipeline to start because the authentication process with the database takes time.

I would rate the scalability a seven out of ten. 

The scalability of PostgreSQL has positively impacted our database solution.

We have an internal support team who handles technical issues.

We use both Microsoft SQL Server and Postgres.

We use Postgres mainly for reporting. SQL server is for running the pipelines.

The deployment was straightforward. Not that long, it took maybe two weeks.

Our team developed the code, and we gave it to another team for deployment. They actually do the deployment work.

We have a dedicated team who handles deployment and maintenance.

The ROI is good. Since most of the BI reports run on PostgreSQL, ROI is there. 

Our company pays for it. There are free versions available, but for advanced features, you obviously have to pay.

Overall, I would rate the solution an eight out of ten. I would recommend using it. 

It has easy plug-and-play features. Even those without much database knowledge can try it out.

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

We often find the solution's datetime datatype challenging.

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

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

We faced no difficulty in installing PostgreSQL.

It took us five minutes to deploy the solution.

Overall, I rate PostgreSQL an eight out of ten.

We use PostgreSQL in our company for test systems.

PostgreSQL is very powerful, easy to manage, and has many features.

PostgreSQL’s performance could be improved.

I have been using PostgreSQL for 17 years.

PostgreSQL is a stable solution.

We added some more volume to PostgreSQL, and it works fine. More than 200 users are using the solution in our organization.

We use the open-source version of PostgreSQL and not the enterprise edition.

I started with PostgreSQL version 8, and currently, I have version 15. I would recommend PostgreSQL to other users.

Overall, I rate PostgreSQL a nine out of ten.

In my current company, we use a wide array of databases, like, Cassandra, Elasticsearch, MongoDB, and Postgres. But here, We specifically use Postgres for transactional purposes.

Since, NoSQL database does not have any, like, transactional-based things. It is called asset property. Since SQL databases possess these asset properties, we primarily rely on SQL, particularly Postgres, due to its superior indexing and performance advantages given our scale.

Compared to MySQL, Postgres has some functions called JSONB aggregators or other aggregators, which are quite useful. Indexing is better in Postgre due to the algorithm it uses, such as B-tree indexing. 

Moreover, Postgres has a specific data type called JSONB, which stores JSON in binary format, resulting in optimized performance.

We have to set up event API, which takes a lot of events from the user. For us, Postgres DB wasn't performant enough to use, so we had a bottleneck there. We use Cassandra, which drastically improves but isn’t a drawback of Postgres. It is common with most SQL databases.

I have been working with Postgre for the past year and a half. 

Since we are using Postgre for maintenance purposes, we haven't encountered any issues thus far.

I rate the solution’ stability a ten out of ten.

When it comes to an open-source SQL database, Postgres is highly scalable. You can easily implement partial configurations and streaming replication factors. Postgres offers most of the features.

It depends on how they configure things. So if everything is set up well, they should perform great.

I rate the solution’ scalability a nine out of ten.

We use managed database. Since our Tech team is small, consisting of only four people, we have to work on mobile applications, web applications, and the backend. We have to save some developers' time. We usually choose to use managed database services. Managed services are quite easy as they allow us to set up the databases with just a few clicks quickly.

The pricing for managed databases will be much higher than self-managed ones. That's something I'm sure about. When it comes to accurate pricing information, I always prefer their pricing tables.

Postgres is a very performance-based database. It is an all-in-one tool. You can use it as an SQL database or as a NoSQL database. They do have a data type called JSONB. You can use some part of it in a hybrid NoSQL database or as a key-value-based DB. They do have a good number of plugins. So if they have to extend the capabilities, they have a wide variety of plugins. Depending upon use cases, you can use them. For example, to do some cron jobs, you have a plugin called pg_cron, and you can use PostGIS for geospatial applications. PostGIS is a very awesome thing to work with.

Overall, I rate the solution a nine out of ten.

It is a backend database for security. We dump the data, collect the database, and then analyze it using some BI tools.

The system can perform faster analysis by providing it with a lot of memory. Speed is crucial for analytics. Currently, the main reason we haven't adopted Elasticsearch is that we lack the necessary expertise to manage it.

Postgres should focus on building a stronger knowledge base. They also need to expand their integration capabilities, so more tools and resources are available to manage it. But it is more secure than MySQL.

I have been using PostgreSQL for three years.

We are a team of about 32 people, three of them are focused on software development and installations. We also collaborate with a software company that handles the software development. We then present it to the customer. Our work is primarily focused on security.

Some applications focus on MySQL, while others use Postgres. MySQL to be more is versatile. MySQL seems to have more users, tools, and applications deployed on it, which is why many people default to it over Postgres.

MySQL may have an advantage because it supports more applications and has broader compatibility.

The tool is very easy to deploy and manage. It takes one or two days to complete.

The tool is free of cost. For now, it's not about making money. But once we perfect it, we can offer it to customers willing to pay for support and other services. Most of my deployments are free.

We are primarily a service provider rather than a software developer, though we do have teams experienced in software development. We collaborate with an external provider to develop security and cybersecurity software.

Overall, I rate the solution a seven out of ten.

We use the solution to store tables. It is stable and performs well.

Stability could be improved.

I have been using PostgreSQL for eight months.

The product is stable.

I rate the solution’s stability a seven out of ten.

4 users including developer and manager are using this solution.

The solution needs a third party vendor for deployment.

There is no cost, and it does what it's supposed to do.

We are using the free version of the solution.

We looked up MangoDB. MongoDB is a different type of database. It depends on the requirements. It is more geared towards application-based queries for data integrity and similar tasks. MongoDB is more document-oriented. While most databases follow SQL structure for inserting or retrieving information, MongoDB operates differently. It uses different methods for storing and retrieving data.

The json support is good in PostgreSQL. I would recommend it for small deployments.

Overall, I rate the solution a seven out of ten.

I use PostgreSQL on-premises to store monitoring data collected by  Zabbix Server.

I wanted a database engine that could handle an ingress of a thousand real-time values per second, delete old items without affecting performance, and handle hundreds of user queries at all times.

The solution had to support high compression and time series data while maintaining data integrity and performance.

I wanted the database engine to be easy to tune, secure, and set up.

PostgreSQL matched those requirements and has regular updates and plenty of official and community support resources.

PostgreSQL greatly improved our monitoring solutions data storage, performance, compression, and processing. Our monitoring solutions run efficiently with little maintenance.

The availability, stability, and reliability of our monitoring solutions greatly improved because the database engine scales out well, is easy to tune, easy to upgrade and manage, and supports extensions and plugins for specific use cases. One such plugin is TimescaleDB and it has proved greatly beneficial for time-series data storage and automatic partitioning of the database.The upgrade of the database has been great too, from 12 to 13 to version 14.

The most valuable feature is support for the Timescale DB extension. We managed to reduce the storage space needed to 10% of the original size, without affecting data integrity, and we significantly improved the performance.

The database engine is easy to manage, the tuning is friendly, and the integration with supported extensions is friendly too.

The database engine is free and open-source, too. Since we did everything internally, it has greatly reduced the costs of setting up our systems.

It also supports diverse kinds of replication, which is crucial for a high availability environment that we plan to set in the near future.

PostgreSQL uses high memory compared to its counterparts when a highly demanding workload with many database connections is in use, especially one that makes many concurrent connections to the database. 

Like many other databases, the tuning is manual through a configuration file. It would be useful if the database engine could detect the specifications of the machine in which it is installed and so bring some levels of auto-tuning. 

PostgreSQL replication support isn't so straightforward for multi-sources and master replicas. It will be great if native support of those replication modes become available in the future.

I have been using PostgreSQL for more than four years.

Stability-wise, I have a great impression.

It can be easily scaled.

We haven't used the official support but judging from the available resources on the website and other outlets it seems their support is good.

Positive

I used other database management systems (MySQL and its variant MariaDB) for my NMS applications before moving to PostgreSQL. I had some optimization issues on MySQL and MariaDB and decided to switch to PostgreSQL, mainly for the TimescaleDB extension support provided on PostgreSQL and which my application natively support including automatic database partitioning and compression. TimescaleDB proved to be helpful since I mostly deal with time series data and the TimescaleDB hypertables improved my applications perfomance greatly.

The initial setup was straightforward, although it needed time to get everything well-tuned. 

I implemented in-house.

The ROI is 100%.

PostgreSQL is free and open-source, so if capable admins are available then the setup cost can be negligible. We use internal resources, so it was completely free for us. One can choose the available official support too.

I evaluated other options including MySQL and its variant MariaDB & Percona Server for MySQL, Oracle DB, and SQLite.

For anybody who is considering this solution, my advice is that it is better to do enough research on the specific database engine requirements.

I highly recommend PostgreSQL with TimescaleDB extension for time-series data.