Skip to main content
An Aurora PostgreSQL management call and a PostgreSQL connection follow different routes. Cloud Adapter serves supported RDS cluster and member API operations; the application connects through the configured native PostgreSQL endpoint or approved compatibility connection route. Start with the directed Aurora PostgreSQL service profile. Its target-specific operation table and topology notes determine what your install can create, describe and connect to. Do not infer reader, failover or endpoint parity from another target’s profile.

​
Read cluster, member and session evidence separately

For an install that publishes a compatible RDS endpoint, use the configured address and authorized AWS profile:
Replace these identifiers and address with the installed values. Check the cluster and its members independently; a cluster record does not imply every requested member or endpoint is ready. In the managed service profile, accepted requests are retained and native resources reconciled asynchronously. Follow the exact identifiers with bounded reads and compare with the native target’s resource state. A timeout on CreateDBCluster or CreateDBInstance leaves the outcome uncertain; another create is not a status query. Native AWS documents Aurora endpoint discovery, but your configured adapter may represent endpoints differently according to its directed profile.

​
Check the selected connection mode

The Aurora tuning guide describes target-specific choices, especially AlloyDB native and proxy modes. In one supported native mode, logical readers can have separate member endpoints and no combined reader endpoint. In a proxy-capable deployment, the compatibility listener has its own certificate, identity and network requirements; it does not provide transaction replay or session pooling. Those statements apply to the documented directed target and mode, not every Aurora adapter. Confirm the installed mode, selected endpoint and member role before deciding that a connection error is a failover error. After discovering the expected endpoint, test from the application’s network path with the protected libpq service entry for that exact route:
This query is read-only. Its result identifies the SQL principal, database, reported PostgreSQL version and whether the connected server is in recovery; it does not guarantee a future connection lands on the same server. A successful AWS RDS API call uses SigV4 management credentials and does not establish SQL authentication. A timeout points to the native hostname, port, DNS, subnet route, firewall or listener. A certificate or hostname failure points to the client’s TLS trust and chosen endpoint. A PostgreSQL FATAL response points to database identity or authentication. AWS’s Aurora PostgreSQL connection guide describes native connection information; use the target provider’s corresponding network and TLS procedure for an adapted deployment.

​
Compare reader investigations on AlloyDB and Cloud SQL

These illustrative cases start with the same symptom: a reporting client expected a reader, but writer load remains high. Keep cluster/member identifiers, connection mode, adapter version, native engine version and actual application endpoints with the evidence. Read the cluster and member through the configured RDS management endpoint before inspecting the target.

​
AlloyDB native mode: choose the intended read pool explicitly

For Aurora PostgreSQL → AlloyDB, check the existing creation configuration for t9:tuning:alloydb.mode=native. The first accepted logical member creates the primary; subsequent members map to independent read pools. With multiple readers, this mode does not supply one combined cluster reader endpoint. A pool’s node count is capacity within that pool, not a set of separately addressable Aurora instances. Use the physical AlloyDB cluster and instance identities from the installed mapping for a target-side read:
The native instance read and protected SQL service entry must identify the intended reporting pool. Expected evidence is an available native read-pool instance plus a reporting client configured for that member’s endpoint. Correlate session observations with the endpoint and native pool monitoring; a server address alone is not a permanent pool identity. If the client still uses the writer hostname, repair endpoint assignment rather than adding reader nodes. A read pool is not a promotion candidate: an RDS failover request is outside this mapping’s supported management subset.

​
Cloud SQL: inspect the native replica and its connection route

For Aurora PostgreSQL → Cloud SQL for PostgreSQL, the directed profile uses Cloud SQL’s primary/read-replica model. The AlloyDB mode and read-pool-node-count tags do not configure this target. Describe the mapped reader instance, then use its approved protected connection entry:
Compare native replica relationship/state, the logical member’s published endpoint and the application’s actual hostname. If the native replica exists but the application routes to the primary, changing replica size cannot move that traffic. If the client reaches the intended replica but a recent change is absent, inspect replication progress and the application’s freshness requirement; do not infer current data from management readiness alone. Preserve the target’s documented replication semantics rather than assuming Aurora’s shared-storage behavior. Both examples use native PostgreSQL protocol diagnostics. They neither submit application SQL through RDS management APIs nor establish automatic SQL-plan capture for every database query.

​
Worked case: a reader appears, but reports still hit the writer

Suppose a new logical reader was accepted for orders-cluster, yet the reporting application sees writer load and its fresh connections sometimes fail. First read DescribeDBClusters and DescribeDBInstances for the exact cluster and reader identifiers. Record their statuses and endpoints, then inspect the target’s actual member or pool state. Do not infer readiness from the create response alone. Next, compare the application’s configured reporting hostname with the endpoint model in the directed profile. For AlloyDB native mode, a separate logical reader endpoint may require the application to select that member explicitly; a supposed shared reader address is not proof of routing. For a proxy mode, check the listener address and certificate path separately from the native database. Use the read-only SQL command above against the reporting service entry, and record the returned role, database, version and recovery state. A fresh-connection failure with working old sessions suggests checking the new-login path, including listener reachability, credentials, TLS and connection limits, before changing the cluster. Repeating a reporting write or cluster creation would add effects without resolving endpoint selection. If the session connects but its memory or timeout setting differs from the requested value, read effective pg_settings as that same role and endpoint:
Aurora-style logical cluster and instance parameter groups have different scopes; a requested override may also be unsupported by the native target, pending a restart, or superseded in a session. Compare desired group values with this live SQL result rather than treating a group description as the session value. See Tuning AWS Aurora PostgreSQL.

​
Read reports without changing the cluster

Preserve any x-t9-explain-id receipt from the original RDS operation. Retrieve the separate explanation through T9CloudAdapter.GetExplanation on the install’s dedicated t9 endpoint, signed for service t9 by the exact original IAM owner and session. Report access is scoped to that owner; another role session does not inherit it. A report normally expires 24 hours after creation, and reading it does not renew retention. An unavailable or incomplete report says nothing conclusive about cluster or member effects. Follow Troubleshooting Explanations for bounded polling and export evidence before acknowledgment or expiry. Do not replay an ambiguous create to refresh diagnostics. PostgreSQL query-plan reporting remains planned and requires qualification for a supported PostgreSQL-backed service statement. It is not an Aurora management API or an endpoint for arbitrary application SQL EXPLAIN. Where supported, a plan is an estimate for a specific observed statement context; it does not prove a query ran or a write committed. The full plan may include relation names, predicates and literal values and is available only to the exact report owner. Handle exports as sensitive data. A Support Agent can help reconcile logical members, native reader topology and application routing before a capacity or endpoint change.