Which PostgreSQL high availability model fits your team
If your team needs highly available PostgreSQL and already runs virtual machines, choose Patroni on those VMs with a distributed configuration store such as etcd, Consul or ZooKeeper. If your workloads already run on Kubernetes and your platform team can operate it, CloudNativePG is the better fit. A managed service such as Amazon RDS for PostgreSQL is the right choice when you want the provider to run failover, patching and backups and you accept less control over the underlying layers. The condition that decides this is less the database than where your operators already have skills and where your other workloads run. PostgreSQL itself does not detect a failed primary or promote a standby, so on self-managed servers automatic failover depends on an external tool. Patroni and CloudNativePG both supply that mechanism, but they do it in different places: Patroni in its own process layer with a configuration store, CloudNativePG through the Kubernetes API server.
Patroni fits teams that run PostgreSQL on VMs and want a tool that is mature, MIT licensed and supports a wide range of PostgreSQL versions. Its advantages matter most when you already operate an etcd or Consul cluster, because Patroni depends on that store for leader election and its REST API exposes switchover, failover and cluster status for your existing monitoring. Confirm that your operators can maintain the configuration store and the per-deployment Patroni settings, since Patroni is described as a template that needs configuration for each deployment. CloudNativePG fits teams that already run Kubernetes and want the database lifecycle managed as Kubernetes objects, with failover handled through the API server and no separate configuration store. Its advantage matters when your platform engineers are comfortable with operators, storage classes and persistent volume claims. Ask how your cluster's storage and node layout will affect failover times before committing.
A managed service such as Amazon RDS for PostgreSQL shifts failover, storage and much of the patching work to the provider. Its Multi-AZ options differ in ways that matter for reads: a Multi-AZ DB instance has one standby that provides failover but does not serve reads, while a Multi-AZ DB cluster has two standbys that also serve read traffic. The cost of this model is control: you cannot choose the replication topology, the configuration store or the host layout the way you can on VMs or Kubernetes, and the first account you create is a member of the rds_superuser role, so review what that role can change in your environment. Before you decide, confirm with your provider which failover and flow control behaviors apply to your region and cluster type, and how your compliance evidence will be produced.
Patroni, CloudNativePG and managed PostgreSQL side by side
This table compares how each option handles failover, its configuration store or control plane, readable standbys, version control, backups, licensing and who operates each layer. Read it by row: the rows that matter most are the ones tied to where your databases already run and who on your team will carry the pager.
| Dimension | Patroni on virtual machines | CloudNativePG on Kubernetes | Amazon RDS for PostgreSQL |
|---|---|---|---|
| Failover mechanism | External tool that elects a leader through a distributed configuration store and promotes a standby; PostgreSQL itself does not detect failure or promote | Operator uses the Kubernetes API server for failover without external tools such as Patroni, with quorum-based failover supported | Managed by AWS; Multi-AZ handles failover, and you confirm the failover behavior for your deployment type in the RDS documentation |
| Configuration store or control plane | ZooKeeper, etcd, Consul or Kubernetes as the distributed configuration store, which you run and secure yourself | Kubernetes API server and cluster control plane, which your platform team must already operate | AWS control plane; no configuration store is exposed to you |
| Readable standbys | Hot standbys serve read-only queries; read routing depends on your proxy or service design, so confirm it in your own setup | Standbys can serve reads through the operator's services; confirm the exact read service configuration for your version | Multi-AZ DB instance: one standby that does not serve reads. Multi-AZ DB cluster: two readers that serve read traffic |
| PostgreSQL version control | You choose the PostgreSQL major and minor versions; Patroni runs PostgreSQL 9.3 to 18 | Operator manages the PostgreSQL versions supported by the PostgreSQL Global Development Group; confirm the image and version policy you adopt | Version choice and upgrade windows are set by AWS within the options RDS offers; confirm the supported engine versions and your upgrade path |
| Backup tooling | Chosen by you (for example pgBackRest or Barman); Patroni itself does not provide backups, so confirm the tool and its restore testing | Object storage backups through the Barman Cloud plugin, volume snapshots and WAL archiving with point-in-time recovery | Automated backups and point-in-time recovery offered by the service; confirm retention settings and restore procedures in your account |
| Licensing | MIT licensed; no paid edition is required to run Patroni | Apache-2.0 CNCF Sandbox project; PostgreSQL itself is under the PostgreSQL License | Proprietary managed service billed by AWS; PostgreSQL engine license terms apply to the database, with service terms set by AWS |
| Control over OS and parameters | Full control over operating system, kernel, PostgreSQL parameters and extensions, within your change process | Control over PostgreSQL parameters and images through the operator; host OS is governed by your Kubernetes nodes | Limited to parameter groups and supported extensions; confirm which OS and superuser-level actions are blocked on your engine |
| Who operates each layer | Your team or a partner operates the OS, the configuration store, Patroni, PostgreSQL, backups and upgrades | Your platform team operates Kubernetes and storage; the operator automates PostgreSQL lifecycle, and your database team still owns schema, tuning and restores | AWS operates the hosts, failover mechanism and patching windows; your team owns schema, users, parameters and application behavior |
How each option is built: components and topology
All three options keep a writer and one or more standbys, but the moving parts that decide failover differ. Patroni adds an external configuration store and a REST API around PostgreSQL, CloudNativePG moves coordination into the Kubernetes API server, and Amazon RDS hides the topology behind a managed service. The cards below set out what you operate in each design and what to verify before you commit.
Patroni nodes and configuration store
Patroni runs beside each PostgreSQL server and uses a distributed configuration store (ZooKeeper, etcd, Consul or Kubernetes) to hold the leader key. Whichever node holds that key is the primary, so the store's own availability and quorum set the ceiling for your failover design. You operate the PostgreSQL nodes, the store and the Patroni configuration on every node, so confirm who owns each of those three layers before go-live. The store is a separate cluster you must run and monitor.
Patroni REST API for control
Patroni exposes a REST API for health checks, cluster status, configuration, switchover and failover, restarts, reloads and reinitialization. Load balancers and monitoring can use its health endpoints to route traffic to the current primary. Ask your team which automation calls these endpoints, and whether switchover and failover are exposed only to operators with appropriate access on your network.
CloudNativePG operator and Kubernetes API
CloudNativePG is an operator that manages the PostgreSQL cluster as Kubernetes resources and uses the Kubernetes API server for failover, without an external tool such as Patroni. It supports quorum-based failover and synchronous replication. Your platform team owns the Kubernetes control plane and its etcd, so a database failover depends on that control plane being healthy. Confirm how your clusters behave during a control plane outage.
Direct PVC management in CloudNativePG
CloudNativePG manages persistent volume claims directly rather than through StatefulSets. Each PostgreSQL instance keeps its own volume, and the operator decides which instance is promoted. Storage class, volume snapshot support and node placement therefore need explicit planning in your cluster. Ask whether your storage backend supports the snapshot and restore flow you intend to use for backups.
RDS writer and Availability Zone standbys
A Multi-AZ DB cluster on Amazon RDS has a writer and two reader instances across three Availability Zones. The readers acknowledge commits through semisynchronous replication, and failover time for RDS for PostgreSQL depends on the lower replica lag of the two readers. You do not see or configure the underlying nodes, so the topology is something to verify in the service documentation for your region and engine version.
RDS flow control extension
The RDS flow control extension delays writer transactions by default when any reader lags more than two minutes, and the setting can be adjusted with flow_control.target_standby_apply_lag. This trades write latency for bounded reader lag, which matters if your application reads from standbys. Check whether your workload accepts slower writes during replica lag, and which parameter group controls the threshold in your account.
Which option fits your environment and team
This fits a team that already runs virtual machines, has someone who operates a distributed configuration store such as etcd, Consul, ZooKeeper or Kubernetes as a store, and wants PostgreSQL on hosts it controls. Patroni is MIT licensed and runs PostgreSQL 9.3 to 18 using one of those stores, so the failover logic lives in a tool you configure and operate yourselves. PostgreSQL itself does not detect a primary failure or promote a standby, so this external layer is required.
- Skills needed: Linux administration, PostgreSQL replication and failover design, and operation of the chosen configuration store, including its quorum and backups.
- Layers you own: the OS, watchdog and network setup, PostgreSQL parameters, synchronous replication settings, backups, schema, and roles.
- REST control surface: Patroni exposes a REST API for health checks, cluster status, switchover, failover, restarts and reinitialization, which your automation can call.
- Standby options: synchronous replication including quorum commit, and standby clusters, are supported, so you can design for your own recovery targets.
- Best fit when: your VM platform and configuration store already have operators, and you need PostgreSQL to sit beside other workloads on the same estate.
Before committing, confirm with your team which configuration store you will run, who patches it, and how the watchdog and memory limits on your hosts will behave under Patroni.
This fits an organization where platform engineers already run Kubernetes in production and treat stateful workloads as normal cluster citizens. CloudNativePG is an Apache-2.0 CNCF Sandbox operator that manages persistent volume claims directly instead of using StatefulSets, and it uses the Kubernetes API server for failover without an external tool such as Patroni. The database becomes one more resource your GitOps and cluster tooling already manages.
- Skills needed: Kubernetes operations, storage class and volume snapshot knowledge, and comfort with operator upgrades and custom resources.
- Layers you own: the Kubernetes control plane and node OS, storage backend, PostgreSQL parameters, backup target and retention, schema, and roles.
- Backup tooling: backups to object storage through the Barman Cloud plugin, volume snapshots and WAL archiving with point-in-time recovery are documented, so confirm which combination your recovery objectives need.
- Pooling and versions: built-in PgBouncer pooling and management of PostgreSQL versions supported by the PostgreSQL Global Development Group are included.
- Best fit when: the platform team already owns cluster lifecycle, and you want database changes to follow the same review and deployment path as other services.
Ask the vendor or your platform team to confirm how storage class performance, node drains and operator upgrades interact with your replication settings in a test cluster.
This fits a team that wants the cloud provider to run the database infrastructure, including host patching, Multi-AZ failover and much of the replication plumbing, and that accepts less control over PostgreSQL internals in exchange. Amazon RDS for PostgreSQL offers a Multi-AZ DB instance with one standby that provides failover but does not serve reads, or a Multi-AZ DB cluster with two standbys that provide failover and also serve read traffic.
- Skills needed: cloud networking, IAM, database schema and query work, and monitoring of managed metrics. Less time goes to replication and host operations.
- Layers you still own: schema, application roles, query design, and the parameter groups you are allowed to set. The first account created is a member of rds_superuser, so plan role separation from the start.
- Control you give up: the flow control extension can delay writer transactions when a reader lags more than two minutes by default, and failover time depends on the lowest replica lag of the two readers. Confirm these settings against your latency needs.
- Cost shape: the bill is recurring and driven by instance class, storage, I/O and data transfer. Ask the provider for the pricing model for your region and workload.
- Best fit when: your organization already standardizes on one cloud, the workload fits the managed parameter set, and no one on the team wants to run replication or host patching.
Check the provider's documentation for the exact parameters you can change and the exit path for moving data out if you need it later.
Why failover design and readable standbys differ
PostgreSQL gives you hot standbys that serve read-only queries, plus both synchronous replication, where a commit waits for standbys, and asynchronous replication. What it does not give you is failover. The PostgreSQL failover documentation is explicit that the server has no software to detect a failed primary and promote a standby, so on self-managed servers that job belongs to an external tool. With Patroni, that tool is a process on each node that uses a distributed configuration store (ZooKeeper, etcd, Consul or Kubernetes) to hold a leader lock. Whichever node holds the lock is the primary, and when the lock lapses, a healthy standby can take it. Your team owns the configuration store, its quorum and the health of the Patroni agents, and those are the components to design and test first.
CloudNativePG takes a different route. It uses the Kubernetes API server to coordinate failover, so there is no separate consensus cluster to operate. Its documentation describes quorum-based failover and synchronous replication settings that you must set for each cluster. The trade-off is that your failover behavior is tied to Kubernetes control plane health and to how the operator's pods, persistent volume claims and scheduling are configured. Ask the vendor or project to show how the cluster exposes read-only endpoints for standbys in the version you plan to run, and test that application connection strings reach a replica as you expect.
Amazon RDS Multi-AZ DB clusters hide the failover mechanism behind a managed writer and two readers across three Availability Zones. Replication is semisynchronous, so at least one reader must acknowledge a commit. For RDS for PostgreSQL, failover time depends on the reader with the lowest replica lag, and a flow control extension delays writer transactions by default when any reader lags more than two minutes. That delay can be tuned with flow_control.target_standby_apply_lag. The reader should verify this setting in the RDS documentation for their engine version and decide whether a slower writer is acceptable in exchange for a faster, more predictable failover.
How to choose between the three in your environment
This sequence turns the platform trade-offs into a short set of checks against your own estate, so you finish with a shortlist you can defend to your security and operations leads.
Confirm where your workloads already run
Start by listing where the databases will sit: your own virtual machines, an existing Kubernetes platform, or a cloud account where a managed service is already approved. Ask the platform owner who runs that layer today and who would be paged at 2 a.m. If the answer is that no one operates Kubernetes in production, a CloudNativePG choice adds a platform dependency, not just a database. The step is done when you have a written list of environments with an operator named for each. A wrong answer here is the most expensive one, because it forces a rebuild of the hosting layer later.
Confirm the configuration store or Kubernetes platform you can operate
For Patroni on virtual machines, identify the distributed configuration store you already run or are prepared to run: etcd, Consul, ZooKeeper or Kubernetes. The Patroni documentation lists these four options, and each carries its own backup, quorum and upgrade routine that your team must own. For CloudNativePG, confirm the Kubernetes platform, its control plane layout and who patches it. Done means a named team operates the store or cluster, with a documented recovery path. Choosing a store nobody has operated before is a common source of failover incidents that look like database problems.
Decide how much control over parameters and extensions you need
List the PostgreSQL parameters, extensions and authentication methods your applications depend on. Patroni on your own servers gives full access to the PostgreSQL configuration, and PostgreSQL documents methods such as LDAP, certificate and OAuth. Check each requirement against the managed service's documented parameter groups and superuser model. On Amazon RDS for PostgreSQL, the first account created holds the rds_superuser role, so the control boundary differs from a self-managed cluster. Done when every required parameter and extension is marked as supported, supported with conditions, or unavailable. A wrong answer usually surfaces after go-live, when an application needs a setting the service does not expose.
Decide whether read traffic must reach standbys
Determine whether reporting or read-heavy services must query standbys during normal operation. PostgreSQL hot standbys serve read-only queries, and the Amazon RDS documentation describes a Multi-AZ DB instance whose standby provides failover but does not serve reads, and a Multi-AZ DB cluster whose two standbys also serve reads. For the managed option, note that the RDS for PostgreSQL cluster uses a flow control extension that can delay writer transactions when a reader lags more than two minutes by default. Done when you have a read-routing decision and a tested behavior under replica lag. Skipping this check can leave you with a write-path slowdown you did not design for.
Check supported PostgreSQL versions against your upgrade calendar
Compare the PostgreSQL major version you plan to deploy with the PostgreSQL versioning policy. The supported list shows version 14 ending November 12, 2026, version 15 ending November 11, 2027, and version 18 supported until November 14, 2030. Map those dates to your change calendar, then confirm the Patroni and CloudNativePG release lines that support your chosen version, using their release pages. Patroni 4.1.5 and CloudNativePG 1.30.1 are the current lines named in the supplied facts. Done when you have a dated upgrade path for the major version and a named owner for it. A wrong answer leaves you running an unsupported engine while the platform layer keeps moving.
Map backup, restore and point-in-time recovery requirements
Write down your recovery point and recovery time requirements, then check how each option provides them. CloudNativePG supports backups to object storage through the Barman Cloud plugin, volume snapshots and WAL archiving with point-in-time recovery. Patroni leaves backup tooling to you, so confirm the archiving method and the restore drill owner. For the managed service, confirm the retention and restore options in its documentation and whether you can export data to your own storage. Done when a restore test has been scheduled for each option on your shortlist. Assuming backups work because replication works is a frequent and costly mistake.
Price the operating roles and the exit path
Assign who operates each layer: database administrators, platform engineers, and the cloud or infrastructure team. Ask any implementation partner for a fixed-scope written quote that lists these roles and the handover items, since DeployOpen does not publish a price list and quotes follow from the written scope. Then document the exit path: moving a self-managed cluster to a managed service or the reverse uses logical replication or dump and restore, and the PostgreSQL upgrading documentation notes that logical replication can work across major versions. Done when the shortlist has a named owner per layer and a documented exit. Leaving this unanswered makes the cost of switching a surprise later.
What control you give up on a managed PostgreSQL service
On a managed service such as Amazon RDS for PostgreSQL, the provider takes on the host, the storage layer and the failover mechanism, and the team keeps the database design and the application contract. The first database account created on an RDS for PostgreSQL instance is a member of the rds_superuser role and holds rds_superuser privileges, so that account is powerful enough to change most of the database, but it is still not operating-system access. You cannot log in to the host, install an agent beside PostgreSQL, change kernel settings or run your own watchdog as you can with Patroni on virtual machines, where the patroni.yml file, the PostgreSQL data directory and the Patroni REST API sit under your administration. Confirm in the RDS parameter group documentation which parameters you can set and which the provider controls before you assume any tuning path exists.
The trade-off sits in the failover path. On a Multi-AZ DB cluster, the provider decides how the writer and readers are placed, how the flow control extension behaves and how promotion happens, and you cannot read or replay that logic line by line the way you can read Patroni's configuration and logs. Your team can still test the outcome: schedule a controlled failover, measure how long client connections take to recover, and check that application retry logic handles dropped sessions. Ask the provider for its failover behavior in writing, including the replica lag conditions it uses, and record your own test results as audit evidence. A self-managed design gives you the source and the logs, but it also makes you responsible for proving that the failover works.
Several layers stay with your team in both models. You own the schema, the role model beyond the bootstrap account, extension choices, the connection pooling and timeout settings your applications rely on, and the backup restore procedure you have actually rehearsed. Keep the database administrator access list separate from application credentials, and decide early whether the rds_superuser account is used only for break-glass work. Before signing, ask the provider which extensions are available on your target PostgreSQL version, how major version upgrades are scheduled, and what evidence it gives for your own compliance assessment, because those answers decide how much control you actually keep.
Upgrades, backups, monitoring and skills for each option
This table compares who handles upgrades, backups, pooling, monitoring and day-two skills for Patroni on VMs, CloudNativePG on Kubernetes and a managed service. Read each row as a split of responsibility: the question is which layer your team owns and which the provider or operator covers.
| Operating area | Patroni on virtual machines | CloudNativePG on Kubernetes | Managed PostgreSQL (for example Amazon RDS) |
|---|---|---|---|
| Minor upgrades | Your team replaces PostgreSQL executables on each node and restarts, sequencing standbys and the leader. Minor releases do not change the storage format. | The operator rolls minor image versions through the cluster. Your team owns the image tag choice, maintenance windows and rollback testing. | The provider schedules and applies minor versions. Confirm the maintenance window, whether you can defer updates and how much downtime to expect. |
| Major upgrades | Use pg_upgrade, a dump and restore, or logical replication, which can cut downtime to several seconds. Your team runs and rehearses each step. | Plan a new cluster on the target major version or use logical replication. The operator supports the versions PostgreSQL maintains, but the cutover is your project. | Major version upgrades are initiated by you through the provider console or API. Confirm the process, downtime and any extension compatibility with the provider. |
| Backup and point-in-time recovery | You select and operate the backup tool and WAL archive. Test restores regularly, because a backup that is never restored is unproven. | Supports backups to object storage through the Barman Cloud plugin, volume snapshot backups and WAL archiving with point-in-time recovery. Your team configures retention and tests restores. | Automated backups and point-in-time restore are offered by the service. Confirm retention limits, where backups are stored and whether you can export them. |
| Connection pooling | Not included. Deploy PgBouncer or another pooler yourself and manage its configuration and high availability. | PgBouncer pooling is built in. Confirm the pooler settings your applications need, since transaction pooling has behavioral limits. | Confirm whether the provider offers a managed proxy or whether you must run your own pooler on compute you control. |
| Monitoring and health | Scrape the Patroni REST API for health, cluster status and failover events, and monitor the configuration store alongside PostgreSQL. | Monitor cluster status through Kubernetes resources and PostgreSQL metrics. Your observability stack needs to reach the cluster namespaces. | Provider metrics and events are available in the console and APIs. Confirm which PostgreSQL-level statistics you can read and how long they are retained. |
| Components you operate | PostgreSQL, Patroni, the configuration store (etcd, Consul, ZooKeeper or Kubernetes), a load balancer or virtual IP, and the REST API endpoints. | PostgreSQL pods, the operator, persistent volume claims, the Kubernetes API server and your storage class. | Very little at the database layer. You still manage schemas, roles, parameters you are allowed to set, application connections and network access. |
| Skills your team needs | Linux administration, PostgreSQL internals, configuration store operations, failover testing and runbook discipline. | Kubernetes operations, storage behavior, PostgreSQL administration and GitOps or manifest handling for database changes. | PostgreSQL administration within provider limits, cloud networking and IAM, and reviewing provider change notices. |
| Questions to confirm | Who on your team holds on-call duty for the configuration store as well as the database, and how often restores are rehearsed. | Which Kubernetes platform and storage class you use, and whether the operator version is covered by your support process. | Which PostgreSQL superuser privileges are restricted, which extensions are available and what you must do to restore to a new instance. |
What buyers ask before hiring outside help for PostgreSQL high availability
How much effort does each option take to run day to day?
Effort depends on who carries each layer. With Patroni on virtual machines, your team runs PostgreSQL, the Patroni agent, the distributed configuration store (etcd, Consul, ZooKeeper or Kubernetes), load balancing and backups, so the layers multiply. With CloudNativePG, the operator handles failover through the Kubernetes API, but your team still owns the Kubernetes cluster, storage classes, backup targets and upgrade windows. With a managed service such as Amazon RDS for PostgreSQL, the provider runs the failover mechanics, but your team still owns schema, query tuning, roles and maintenance windows. Ask any outside team to map each layer to a named owner in a written scope.
Can our own team run Patroni or CloudNativePG without outside help?
Your team can run either option alone if it already operates PostgreSQL in production and has the matching platform skills. Patroni requires per-deployment configuration, a working distributed configuration store and familiarity with its REST API for health checks, switchover and failover. CloudNativePG requires Kubernetes operations skills, including persistent volume claims, backups to object storage and point-in-time recovery through WAL archiving. Outside help usually fits when a team lacks one of these skills, needs a second pair of hands for the first build, or wants the failover, backup and restore tests documented as evidence. Ask for a skills gap review before agreeing the scope.
What does the work need from our infrastructure and Kubernetes staff?
Patroni on virtual machines needs infrastructure staff for hosts, networking between nodes, the configuration store cluster, DNS or connection routing and backup storage. CloudNativePG needs Kubernetes staff for the cluster itself, node placement, storage classes that suit PostgreSQL, network policies, secrets handling and operator upgrades. A managed service shifts most host and failover work to the provider, but your staff still handle networking to the database endpoint, identity, parameter groups and backup retention settings. Before work starts, ask who has administrative access to each layer, who approves changes and which staff receive on-call duties.
How long does a migration take, and what changes the timeline?
No fixed duration is set here, because the timeline depends on database size, the number of applications connecting, the PostgreSQL major version on each side and how much downtime the business accepts. Logical replication works between different PostgreSQL major versions and can keep cutover downtime short, but it does not carry DDL, sequences or large objects, which adds work to the plan. Migrating from a managed service also needs a check of extensions and role privileges, because the first account on Amazon RDS for PostgreSQL holds rds_superuser privileges that a self-managed setup does not provide. Most engagements are fixed-scope, so ask for the timeline, dependencies and acceptance tests in the written scope.
Does a managed service remove the need for a DBA?
A managed service removes much of the failover and host work, but it does not remove database administration. Your team still needs someone to design schemas, tune queries, manage roles and privileges, plan major version upgrades and review backup and recovery settings. The provider's Multi-AZ options also differ in what they deliver: a Multi-AZ DB instance has one standby that does not serve reads, while a Multi-AZ DB cluster has two standbys that serve reads and a flow control extension that can delay writer transactions when a reader lags. Ask which of these tasks stay with your staff and which the provider covers.
How do we get a quote, and what should the written scope include?
DeployOpen does not publish a price list. A quote follows from a written scope, which is agreed before work starts and usually covers a fixed set of deliverables and timelines. Ask for the scope to name the option chosen, the environments (VMs, Kubernetes or a managed service), the number of clusters, the failover and switchover tests, the backup and point-in-time recovery design, the documentation handed over, the upgrade approach for PostgreSQL minor and major releases, and what happens after handover. Ongoing support, upgrades and continuous testing are available as retainers, so ask which items are one-time and which recur. Compare quotes on the same scope, not on the headline total.
How DeployOpen scopes, delivers and supports PostgreSQL high availability
DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so the same engagement can cover a Patroni cluster on virtual machines or a CloudNativePG cluster on Kubernetes. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We confirm which of the three options fits your estate, including where your databases already run and who will operate them.
- The written scope names the PostgreSQL major version, replication mode, failover design and backup targets for your environment.
- We list the identity, network and monitoring integrations that your team needs before work starts, so no item surprises either side.
How we build
- For Patroni, we configure the distributed configuration store, leader election, synchronous replication and the REST API your monitoring will call.
- For CloudNativePG, we set up the operator, storage classes, failover behavior through the Kubernetes API and backups to object storage with WAL archiving.
- We test planned switchover, unplanned primary loss and restore from backup, and record the results against the agreed acceptance criteria.
How we hand over
- Deliverables include architecture notes, runbooks for failover, restore and version upgrades, and the configuration files your team will own.
- We walk your operators through failover drills and the decisions that remain with your team, such as connection pooling and maintenance windows.
- The handover pack records which parts of the stack you run yourselves, so the ownership split is explicit for auditors and procurement.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, and the retainer scope is agreed in writing.
- Upgrade planning covers PostgreSQL minor releases and the move between supported major versions, against the dates in the PostgreSQL versioning policy.
- Compliance evidence, such as configuration records and test logs, is prepared for your assessors, who issue any audit report or certification.
