> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tuning AWS Aurora PostgreSQL

> Tune directed Aurora adapters by cluster mode, reader-pool capacity, parameters and application connections.

An adapter is the origin/target pair. **Aurora PostgreSQL → AlloyDB** and **Aurora PostgreSQL → Cloud SQL** retain the same origin API but have different native capacity and topology. Select the adapter first; tuning adjusts settings within that choice. See [Trade-offs in AWS Aurora PostgreSQL](/cloud-adapter/trade-offs/aws-aurora-postgresql).

## Keep cluster and member controls separate

| Setting                                  | Where it belongs       | Meaning                                                   |
| ---------------------------------------- | ---------------------- | --------------------------------------------------------- |
| `t9:tuning:alloydb.mode`                 | Cluster creation       | `native` or `proxy` connection mode for the whole cluster |
| `t9:tuning:alloydb.read-pool-node-count` | Reader member creation | Native nodes inside that logical reader's pool            |
| `DBInstanceClass`                        | Logical member         | Capacity mapped to a supported target machine shape       |
| Cluster parameter group                  | Cluster members        | Shared supported flag overrides                           |
| Instance parameter group                 | Individual member      | Member-specific supported overrides                       |
| Client pool/concurrency                  | Application            | Connections and query demand sent to the chosen endpoint  |

AlloyDB mode and node-count controls belong to the AlloyDB target namespace. They are not generic tuning keys for Cloud SQL, Azure or other targets. A capacity choice is not a writer-role selector: the first accepted member creates the writer; later members create readers. Do not use member names, promotion tiers or an invented role tag to reorder that contract.

## Example: create with native connections

For a disposable cluster, include these tags in its normal `CreateDBCluster` request. This is a tag fragment, not a complete provisioning command: network, credentials, capacity mappings and database creation arguments still come from your [deployment configuration](/cloud-adapter/configuration/overview).

```json theme={null}
[
  {"Key": "t9:tuning:alloydb.mode", "Value": "native"},
  {"Key": "t9:ack:degradation", "Value": "rds-native-fixed-primary"}
]
```

Native mode is the direct database connection path. The fixed-primary acknowledgement records a consequential topology choice: reader pools do not become writer-promotion candidates. It is not a generic consent to unrelated differences.

With more than one native reader pool, clients use individual member endpoints rather than assuming there is one combined cluster reader endpoint. The application must decide which clients use which reader; a database class setting does not make that assignment.

## Example: give reporting its own capacity

Suppose `orders-dashboard` is already a one-node logical reader and a new `orders-reporting` reader should have three nodes. On the new reader's normal `CreateDBInstance` request, these tags express that pool size and the relevant native-mode acknowledgements:

```json theme={null}
[
  {"Key": "t9:tuning:alloydb.read-pool-node-count", "Value": "3"},
  {"Key": "t9:ack:degradation", "Value": "rds-native-reader-pool"},
  {"Key": "t9:ack:degradation:1", "Value": "rds-native-separate-reader-endpoint"}
]
```

The example assumes the writer and dashboard reader were already accepted. Three is an illustrative capacity choice, not a recommendation. Each node has the member's mapped size; this does not create three independently addressable Aurora instances. Check the admitted count and native quota before provisioning.

Increasing node count and increasing node size solve different problems. More nodes can distribute independent sessions, while a single large query may still need a different plan or more per-node resources. Long-lived connections can pin load unevenly. Test with the actual connection lifecycle rather than a benchmark that opens a new connection for every query.

Select creation-time values before provisioning. Treat a later resize as a managed change through the owning configuration/API workflow, with verification and rollback, not as adding a cosmetic tag to an existing resource. Do not edit adapter-managed native resources behind their configuration owner and assume reconciliation will preserve the change.

## Example: choose compatibility connections deliberately

For a proxy-capable deployment, this is the cluster creation tag set:

```json theme={null}
[
  {"Key": "t9:tuning:alloydb.mode", "Value": "proxy"},
  {"Key": "t9:ack:degradation", "Value": "rds-native-fixed-primary"}
]
```

The deployment needs its proxy listener, frontend certificates, identity configuration and restricted native route. A tag does not create a secure network architecture by itself. In proxy mode, the logical reader endpoint can route across reader pools, so the native separate-reader-endpoint acknowledgement is not needed. Multi-node pool addressing and fixed-primary behavior remain distinct considerations.

Proxy mode is not a throughput switch. Each client uses a native database connection; the layer does not provide session pooling or transaction replay. Budget client connections against database capacity and proxy capacity. Inspect new-login latency separately from query latency on established sessions. An authentication dependency can affect new connections while existing sessions continue.

For interactive traffic, application retry deadlines must leave time for useful work. For writes, distinguish a rejected request from an ambiguous commit; blindly replaying a transaction after losing the connection may duplicate a business action. Use application transaction IDs or another appropriate idempotency design.

## Tune parameters at the right scope

Tensor9 retains logical cluster/instance parameter groups and applies supported explicit overrides to the target's native flags. Cluster settings affect members; instance overrides can specialize a member. Defaults are not the same as an explicit override, and a group description is not a live SQL reading.

Before changing a parameter, record its engine family/version, target-supported values, units and restart behavior. A restart-required change is not made safe by asking for immediate application. Schedule and verify the affected member's restart separately from the logical group edit.

Use the application's SQL role to inspect effective native values:

```sql theme={null}
SELECT name, setting, unit, source, pending_restart
FROM pg_settings
WHERE name IN ('work_mem', 'statement_timeout', 'max_connections');
```

The output may differ between members or between sessions with overrides. Tune a reporting query transaction-locally before proposing a cluster-wide memory change; see the bounded SQL experiment in [Tuning AWS RDS PostgreSQL](/cloud-adapter/tuning/aws-rds-postgresql#example-test-a-reporting-query-setting-safely).

## Validate a reader-capacity change

<Steps>
  <Step title="Establish an isolated baseline">
    Use a disposable cluster with a copy of representative schema/data and no production writers. Record directed adapter, connection mode, member sizes, node counts, client endpoint assignment and application connection limits. Assign interactive traffic to `orders-dashboard` and reports to `orders-reporting` explicitly.

    Set your own acceptance budgets for dashboard tail latency, reporting completion time, writer latency and total hourly spend. Do not use illustrative values from an example as service guarantees.
  </Step>

  <Step title="Observe each pool separately">
    Configure protected PostgreSQL connection services `orders-dashboard-test` and `orders-reporting-test` for the disposable endpoints using the deployment's approved TLS/authentication route. Inspect the role and session before sending traffic:

    ```bash theme={null}
    psql 'service=orders-dashboard-test' -X -v ON_ERROR_STOP=1 \
      -c 'SELECT current_user, current_database(), inet_server_addr();'
    psql 'service=orders-reporting-test' -X -v ON_ERROR_STOP=1 \
      -c 'SELECT current_user, current_database(), inet_server_addr();'
    ```

    A server address is a diagnostic observation, not a permanent member identity. Combine it with the configured logical endpoint and native pool monitoring. Verify the clients are actually using the intended endpoints.
  </Step>

  <Step title="Change one capacity dimension">
    Re-run the same bounded workload with one candidate change: reporting node count, reporting node size or application concurrency. Keep the dataset, query mix, dashboard traffic and writer traffic constant. Exercise both fresh and long-lived connections.

    Record connection wait, errors, query latency distribution and native per-pool CPU/memory/connection observations. Also inspect writer behavior. Extra reporting capacity is useful only if it improves the intended workload without violating the other acceptance budgets.
  </Step>

  <Step title="Test reconnect behavior and decide">
    In the disposable deployment's approved maintenance procedure, interrupt one reader route and observe application reconnect, timeouts and resumed queries. Do not perform the exercise against a production pool. Verify that reporting clients do not silently fall onto the interactive pool and defeat the intended isolation.

    Accept the change only when both normal and recovery behavior meet your budgets. Restore the prior configuration if it does not. Retain nonsecret measurements, remove temporary clients/service entries, and remove extra test members and their associated network resources through the owning workflow. Confirm the resulting native capacity and charges.
  </Step>
</Steps>

## Other PostgreSQL targets

For Aurora PostgreSQL → Cloud SQL or → Azure PostgreSQL Flexible Server, tune the target's primary/replica topology and supported settings, not AlloyDB pool tags. Aurora-specific promotion priority, Serverless capacity units and storage-product choices do not automatically become equivalent native controls. Follow the [target-specific catalog](/cloud-adapter/service-catalog/aws/databases-storage/rds-aurora-postgresql) and preserve the distinction between logical management state and native behavior.

For DigitalOcean, OCI, Scaleway or CloudNativePG mappings, first establish the supported management path, then use its compute, storage, backup and connection controls. Customer-operated PostgreSQL adds responsibility for node/volume placement and recovery tooling. [Tuning AWS RDS PostgreSQL](/cloud-adapter/tuning/aws-rds-postgresql#target-specific-operating-controls) covers these engine-operating concerns; Aurora cluster semantics still require their own qualification.

More reader capacity cannot provide transparent transaction replay, turn readers into writer-promotion candidates, or supply a complete cross-region fencing and recovery protocol. Those requirements belong in the architecture decision.