# Ensure Database Has A Read-Only Node Enabled

- Source: https://support.icompaas.com/support/solutions/articles/ensure-database-has-a-read-only-node-enabled
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [DigitalOcean Cloud](https://support.icompaas.com/support/solutions/c_do_cloud) › [DigitalOcean Rules](https://support.icompaas.com/support/solutions/folders/digitalocean-rules)
- Last updated: 2026-08-13
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

## Description

This rule checks that a Managed Database cluster has at least one read-only node provisioned so read-heavy workloads can be offloaded from the primary. On DigitalOcean, a read-only node is a replica of the primary — it can live in an additional region to reduce latency — and it exposes its own connection endpoint that applications can target for read queries.

The rule inspects the cluster's replica list for a configured read-only node and recommends adding one for clusters where reporting or analytics traffic competes with transactional load. Read-only nodes are distinct from standby nodes: they serve reads but do not provide the automatic failover that a standby node does.

-   Clusters with no read-only replica node provisioned
    
-   Read-heavy or analytics workloads issuing queries directly against the primary node
    

## Rationale

Without a read-only node, every query — transactional writes and heavy reporting reads alike — contends for the single primary's CPU, memory, and I/O. A large analytics query can then degrade latency for the critical transactional path.

Routing read-only traffic to a dedicated replica isolates those workloads, improving performance predictability for the primary and adding a separately addressable copy of the data for read scaling.

## Impact

Pros:

-   Offloads read and reporting traffic from the primary node
    
-   Improves latency and stability for transactional workloads
    
-   A regional read-only node reduces latency for users near that region
    

Cons:

-   Each read-only node is billed as an additional node
    
-   Replication is asynchronous, so reads may be slightly stale
    
-   Applications must be updated to route read queries to the replica endpoint
    

## Default Value

New clusters are created with no read-only nodes; you add them explicitly after the cluster exists.

## Pre-Requisite

-   DigitalOcean Control Panel access with a role that can add nodes to the cluster
    
-   A node size for the replica that equals or exceeds the primary's size
    
-   Application support for a separate read-only connection endpoint
    
-   Optional: a DigitalOcean API token or doctl authenticated (doctl auth init)
    

## Remediation

### Test Plan

Using the DigitalOcean Control Panel:

1.  In the Control Panel, open Databases and click the cluster name.
    
2.  On the Overview page, scroll to the Read-Only Nodes section.
    
3.  Check whether one or more read-only nodes are listed.
    
4.  Pass: At least one read-only node is provisioned and read traffic is (or can be) routed to it.
    
5.  Fail: No read-only node exists for a cluster that would benefit from read/write separation.
    

Using doctl or the API:

List the cluster's read-only replicas.

doctl databases replica list <database-cluster-id>

curl -s -X GET "https://api.digitalocean.com/v2/databases/<database-cluster-uuid>/replicas" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN"

Pass if the replicas list contains at least one read-only node. Fail if the list is empty.

### Implementation Steps

Using the DigitalOcean Control Panel:

1.  On the cluster's Overview page, scroll to the Read-Only Nodes section and click 'Add a read-only node'.
    
2.  Choose a node size at least as large as the primary, select a datacenter region, and name the node.
    
3.  Click 'Create a read-only node' and wait for provisioning.
    
4.  Update the application to send read-only queries to the new node's connection endpoint.
    

Using doctl or the API:

Create a read-only replica with doctl or the replicas endpoint.

doctl databases replica create <database-cluster-id> <replica-name> --size db-s-1vcpu-1gb --region nyc1

curl -s -X POST "https://api.digitalocean.com/v2/databases/<database-cluster-uuid>/replicas" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -H "Content-Type: application/json" -d '{"name":"<replica-name>","size":"db-s-1vcpu-1gb","region":"nyc1"}'

### Backout Plan:

1.  Remove the read-only node with doctl databases replica delete <database-cluster-id> <replica-name>, or DELETE /v2/databases/<database-cluster-uuid>/replicas/<replica-name>.
    
2.  Repoint any application that used the replica endpoint back to the primary before deleting it.
    

## References:

1.  [How to Add Read-Only Nodes to PostgreSQL Database Clusters](https://docs.digitalocean.com/products/databases/postgresql/how-to/add-read-only-nodes/)
    
2.  [doctl databases replica create](https://docs.digitalocean.com/reference/doctl/reference/databases/replica/create/)
    
3.  [doctl databases replica](https://docs.digitalocean.com/reference/doctl/reference/databases/replica/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.