This is a micro blog post about a feature that I failed to praise in Percona Operator for PostgreSQL - ability to expose replicas separately.

The problem is that when you connect to the PostgreSQL cluster through pgBouncer, it routes all you reads and writes to the primary.

So in that case the role pgBouncer plays here:

1. Pool connections
2. Provide single entry point to connect to
3. In case of primary failure reroute quesries to the new primary

But we heard it a few times, that it is not good enough. Sometimes you want to have your application to scale reads and not hammer your primary.

Starting version 2.4.0 we allow users to expose replica nodes separately. It is happening by default for all clusters already. You can see -replicas service:

NAME                TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)          AGE
cluster1-replicas   ClusterIP      10.118.234.58   <none> 
5432:31812/TCP   11h

To change the service type, user should alter spec.expose section:

  expose:
...
  exposeReplicas:
    type: LoadBalancer

With this exposure your application connection is going to look like this:

Percona offers various software options to run PostgreSQL:

• for regular deployments, use battle-tested, performant and reliable Percona Distribution for PostgreSQL;
• deploy, manage, scale your databases in Kubernetes with open source Percona Operator for PostgreSQL;
• want to get RDS-like experience, but with no vendor-lock and fully open source - get slick UI and API with Percona Everest;
• for cloud-based deployments use our SaaS offering - Ivee by Percona (currently in Beta).

And of course if you are looking for help, support, professional support - let our team know: https://www.percona.com/about/contact