PgBouncer and Pgpool – Essential for Scaling PostgreSQL

Companies looking at PostgreSQL as a production database alternative to Oracle typically want their web applications to scale quickly as those expensive commercial alternatives. The competitive modern business landscape – most notably the fickle online customer — demands high performance, and will look elsewhere when encountering a slow eCommerce site. Ensuring high scalability when using Postgres is a must!

Thankfully, the robust open source community around PostgreSQL developed two tools aimed to boosting the database’s performance on high traffic websites. Called PgBouncer and Pgpool, they need to be considered as part of any Postgres implementation. Let’s take a closer look.

A Lightweight Connection Pooler for PostgreSQL

PgBouncer serves as a connection pooler for Postgres. It is a lightweight tool known for a small footprint with minimal overhead. The program simply caches connections to different database servers. Its ability to manage a pool of database connections limits the number of actual connections to each Postgres instance; boosting the overall performance during a high traffic scenario.

Focusing specifically on connection pooling is one of the reasons PgBouncer is able to keep its small footprint. As such, it is not usable for other vital web database functionality, such as load balancing or replication. Pgpool is an option for handling those functions in addition to connection pooling.

Postgres Load Balancing, Replication, and more

Pgpool – now in its second major iteration, so Pgpool-II – is more of a Swiss Army knife of Postgres middleware functionality. In addition to connection pooling, it also performs load balancing, parallel query processing, replication, and failover handling – vital features for any scalable web application database. All client access to a PostgreSQL instance (or multiple instances) is managed through the Pgpool middleware.

Replication and load balancing are essential for any web application receiving high volumes of traffic. Load balancing lets Pgpool-II seamlessly distribute SELECT statements across multiple replicated database servers; improving overall system throughput as a result. As middleware, it mimics the API of Postgres, so a client application connects with Pgpool-II in a similar manner as any PostgreSQL server.

PgBouncer or Pgpool – what Option works Best?

Many system architects and/or database administrators probably wonder whether PgBouncer or Pgpool makes the most sense in their database application. Maybe using both is the best solution? The following database administration blog looks at this question while providing an overview of both tools.

PgBouncer by itself is the wisest choice if connection pooling is the only major need. Maybe a separate load balancer is already in place? This rule also applies to applications hosted in resource-constrained environments where quick database calls with low throughput happen frequently.

Pgpool naturally makes sense if you need its additional features, like replication and load balancing, combined with connection pooling functionality. Both tools work well together in applications where many database connections are expected and PgBouncer’s lower overhead in regards to pooling helps the overall performance.

Whether choosing Pgpool, PgBouncer, or a combination of the two, there’s no denying both tools remain valuable options for any high traffic PostgreSQL application.

Keep returning to the Betica Blog for additional information, advice, and insights from the rich world of software development. Thanks for reading!

Barman and repmgr – Essential Tools for PostgreSQL

If your company’s software engineers are veterans with PostgreSQL, chances are pretty good they are also familiar with the utilities, Barman and repmgr. Barman handles the management of the backup and recovery process for a Postgres instance. While repmgr, as hinted at by its name, performs a similar role with replication – in fact repmgr also offers a measure of integration with Barman.

Let’s take a closer look at both tools to see if they make sense as part of your PostgreSQL implementation. If your team is considering Postgres as a cheaper alternative to Oracle, perhaps this additional information helps make your decision easier. Good luck!

Barman – the PostgreSQL Choice for Disaster Recovery

Developed by the well-known purveyor of Postgres support, training, and development, 2ndQuadrant, Barman is a worthy open source option for organizations needing a tool to handle backups and restores for PostgreSQL. It also plays an important role in any company’s disaster recovery process. Barman helps ensure databases are back online as quickly as possible – a vital factor in achieving business continuity.

In fact, Barman focuses its functionality on disaster recovery scenarios. It supports the remote and hot backups of multiple database servers, while helping DBAs or other network personnel get everything up and running again. The tool also provides remote management capabilities for multiple servers, including ssh support.

Other features include the local storage of metadata, PITR (Point-In-Time-Recovery), file compression, retention policies, incremental backups, tar integration, and more. In short, Barman is a fully functional backup and recovery solution for Postgres. Since it is written in Python, companies with developers skilled in that language can make modifications as needed.

Version 2.1 of Barman was released earlier this year. 2ndQuadrant also provides documentation as well as commercial support and consulting options. As an open source software product, a robust online community is available for advice on usage. Any company using PostgreSQL needs to explore Barman as an option for database backup and disaster recovery.

Manage PostgreSQL Replication with repmgr

Another open source Postgres utility developed by 2ndQuadrant, repmgr handles database replication across multiple PostgreSQL servers. The latest version of repmgr – 3.3.1 – was released in March of 2017, supporting Postgres versions 9.3 and later. It leverages streaming replication and the PostgreSQL 9 Hot Standby feature to ensure superior performance in high scalability and availability environments as well as ease of administration.

One of the unsurprising features of repmgr, considering the developer, is its seamless integration with Barman. You are able to make clones from a Barman archive, instead of accessing a live server. This helps prevent a performance hit on a production server.  If live streaming replication gets interrupted, an archive can be easily used in a pinch.

As with Barman, 2ndQuadrant also provides commercial-level support and consulting options with repmgr. When used together, both tools make it easier for companies to build an industry-leading relational database solution at a fraction of the cost of going with Oracle. It is yet another example of the benefits of open source software.

Stay tuned to the Betica Blog for additional news and insights from the wide world of software development. As always, thanks for reading!

The NoSQL Capabilities of PostgreSQL

Many businesses of all sizes leverage PostgreSQL as an open source option to Oracle and other relational databases. Significant cost savings while maintaining a similar level of performance remains a preeminent reason for this switch. A robust community and the availability of commercial-grade support make Postgres worthy of consideration for your traditional database needs. 

With NoSQL gaining popularity all over the technology world, you may wonder how PostgreSQL supports this new database paradigm. Let’s take a look at what functionality exists today in the database with a quick towards the future as well.

Postgres NoSQL for the Enterprise

We’ve talked about EnterpriseDB’s commercial level version of PostgreSQL previously on the blog. The company also offers a Postgres version with support for document databases and key-value stores – two of the most common NoSQL database types. Known as Postgres NoSQL for the Enterprise, this is something worthy of closer attention at companies looking for an open source mix of relational and NoSQL databases.

This Postgres database solution combines the speed and flexibility of NoSQL with the traditional SQL database functionality required for enterprise use – most notably the support for ACID (atomic, consistent, isolated, and durable) transactions. Database instances also easily integrate into the existing business data infrastructure, no matter the platform. In short, it provides the best of both worlds – relational and NoSQL.

ACID transactions are vital for business organizations that depend on the real-time validity of the relationships within its data. Many current NoSQL databases don’t offer this feature, instead following the BASE paradigm which emphasizes speed and availability over the consistency of the data. Postgres NoSQL lets companies combine unstructured and structured data; mixing the performance of NoSQL with the more formalized governance of traditional SQL.

Postgres NoSQL supports many industry standards for programmatic access and data exchange. These include Ruby, Python, and JavaScript for the former, and the JSON and XML formats in the latter case. The superior performance of PostgreSQL combined with the seamless scalability typical of a NoSQL database solution make EnterpriseDB’s combination of Postgres and NoSQL a valid option for any business desiring a flexible database infrastructure.

The Future of PostgreSQL and NoSQL

In a previous article looking at new features of PostgreSQL 10, we noted the relative lack of NoSQL functionality in this newest version of Postgres, slated for release later this year. The new XMLTABLE feature supports the direct querying of data stored in XML documents. Other performance improvements in version 10 bring the speed of the relational database closer to its other NoSQL brethren.

One recent enhancement in Amazon Web Services deserves mention for companies using a mixture of relational and NoSQL databases. The AWS database migration service now includes NoSQL databases, with MongoDB (as a source) and Amazon’s own DynamoDB (as a target) being the first two to be supported. This means companies with a PostgreSQL instance on AWS are able to stream data from Postgres to a DynamoDB instance.

Companies with an investment in PostgreSQL need to explore EnterpriseDB’s NoSQL option to see if any of its features make sense for adding non-traditional database formats to the corporate data infrastructure.

Keep returning to the Betica Blog for additional news and insights from the wide world of software development. Thanks for reading!