Build a Writer-by-Writer Authority Ledger Before Database Cutover

Account for old sessions, reconnects, delayed jobs and effective database permissions before admitting application writes to a separate PostgreSQL target.

Before admitting application writes to a replacement database, identify every source writer, settle its outstanding transactions, and retain separate rejection evidence for old sessions, fresh connections and delayed work. A stopped service, changed DNS record or expired credential does not establish that its existing connections lost write authority. Keep target application admission closed while any required writer or transaction remains unaccounted for. Replication's own target writes are a separate, explicitly scoped exception.

This procedure concerns two separate Amazon RDS for PostgreSQL instances, using PostgreSQL 17 documentation semantics and an existing task-based AWS DMS full-load-and-CDC design on a replication instance. Record the actual complete source/target versions, DMS build, Region, driver and configuration before execution. The article does not establish compatibility for an arbitrary PG17 patch. One application database, ordinary keyed tables and a frozen schema define the working scope. Managed RDS Blue/Green, Aurora, RDS Proxy, active-active replication, schema changes and business-effect replay are excluded. All identities, receipts and outcomes in the worked example are fictional. No database statement or AWS operation was executed.

1. Agree on the database and the acceptance boundary

Cutover lead, with both DBAs: retain the scope sheet and authorized operating window. Identify the source and target by stable resource references as well as endpoints. A hostname by itself is insufficient when configuration can change underneath it. Name the database, schemas, table inventory, replication task and immutable configuration revisions. Keep actual account identifiers and connection secrets in controlled operational evidence, not in a public worksheet.

The DMS operator must confirm the exact source requirements, endpoint roles and logical replication setup against the PostgreSQL source documentation. This procedure starts after the team has chosen and rehearsed that design. It does not create a replication slot, grant endpoint permissions or establish service availability. Full-load completion and independent data comparison are prerequisites supplied by the migration owner.

Separate permission to read evidence from permission to change authority. The approved plan must name who can stop workers, change grants, settle transactions, stop replication and admit target writers. Include the business owner who can decide what happens to an accepted but unfinished operation. Record maximum write-pause duration, uncertainty budget and the person who can declare HOLD. Missing observer access or missing recovery ownership fails this first gate; do not compensate with an assumed clean inventory.

2. Build the writer denominator before measuring coverage

Application and scheduler owners: output a closed writer register and the evidence used to build it. Inventory request-serving instances, queue consumers, scheduled imports, reporting tools that perform updates, repair scripts, deployment migrations, maintenance jobs and direct operator sessions. Include suspended jobs that can be reenabled, disaster-recovery workers and old release replicas. Separate a process revision from a database role: several processes may share a login while behaving differently.

Start with deploy manifests, scheduler definitions, connection-secret consumers, repository connection paths and owner interviews. Then compare those records with observed sessions and database roles. PostgreSQL's statistics documentation describes pg_stat_activity and its visibility limits. An observer with insufficient privileges may see incomplete fields. Statistics observations can also be cached. Retain how the view was obtained, its observation time and visibility, rather than treating one screenshot as exhaustive proof.

A session's application name is a useful hint, not authenticated process identity. Tie it to a deployment revision and role using controlled configuration and runtime evidence. A dormant monthly importer will not appear in a five-minute session sample. If its owner cannot provide the trigger and access path, include an unresolved row instead of removing it from the denominator. Do not report five out of five covered when the sixth known schedule has no evidence.

3. Trace effective permissions, including indirect mutation paths

Source DBA with application owner: produce the effective-path record for each writer. Record direct table and column privileges, reachable memberships, relevant membership options, PUBLIC grants, object ownership and callable routines. A direct UPDATE grant is only one possible route. PostgreSQL GRANT semantics combine access through multiple grant paths; removing one does not establish that the others disappeared.

Check routines that can mutate business objects on the caller's behalf. A SECURITY DEFINER function runs using its owner's privileges. A writer may retain a mutation route through a callable function even when its direct table privileges have been removed. Record the routine identity and revision, its owning authority and allowed operation scope. This is not a request to revoke every function or ownership relationship in production. The DBA chooses specific controls, rehearses their consequences and records the approved change.

Keep the DMS source identity, target apply identity and evidence observer in separate rows. Their operational needs differ from business writers. A role name such as migration does not prove that it is only used by replication. If the application shares a privileged endpoint identity, either separate and rehearse the identities or treat the proposed fence as incomplete. Privileged administration remains an explicit exception with its own change freeze, owner and audit interval, not an ordinary writer falsely marked impossible to use.

4. Design a fence for admission, existing work and reconnects

DBA and process owner: retain a rehearsed control plan per writer. Use three distinct obligations: stop new business work entering the old process, settle already admitted work, and remove or block the specific source mutation path for subsequent attempts. Record what each control accomplishes and what it leaves unaffected. DNS changes address discovery, not every cached endpoint or open connection.

PostgreSQL CONNECT is checked when a connection starts. Its removal is not evidence that an established session was disconnected. Conversely, a disconnected pool can reconnect if a remaining path still permits it. Test the old-session and reconnect cases separately rather than assuming one represents the other.

Read-only defaults are not an immutable privilege boundary. PostgreSQL permits transaction settings to override session defaults through SET TRANSACTION. Similarly, an RDS IAM authentication token expires after 15 minutes, but that expiry does not affect an established session. Record an actual session disposition and effective mutation denial, not a token-expiration time presented as a fence receipt. Never copy the token itself into the ledger.

The control plan must specify how privileged exceptions are supervised. This playbook cannot make a claim that an administrator will never restore permissions. Its acceptance is bounded by named roles, process revisions, objects, controls and an observation interval. If the business needs a stronger isolation boundary, the architecture/security owners must separately design and test it.

5. Prepare probes that actually exercise the intended path

Application owner and DBA, under separate authorization: retain a probe contract before changing controls. Define one controlled operation for each required mutation path, its expected result before fencing and expected denial afterward. Bind the probe to a writer revision, database identity, object/routine path and operation ID. Without a pre-fence positive control or equivalent validated reachability evidence, a failed attempt could simply target the wrong database.

Use an isolated rehearsal environment and a deliberately safe dataset first. Decide whether the probe must commit to establish the intended behavior and who verifies cleanup. A transaction that is later rolled back is not automatically harmless: routines, sequences and external effects require their own review. Do not insert into a live business table merely to produce a green checkbox. An agreed inert production probe, if any, needs explicit approval and a defined effect-isolation/cleanup contract.

A rejection receipt contains the attempted identity and destination, connection mode, operation ID, time interval, actual result and independent state readback. Distinguish permission denial from timeout, DNS failure, pool exhaustion or missing evidence. A timeout is inconclusive, not a demonstrated denial. Attach the actual error and bounded readback privately; the public specimen uses aliases only. No canned error message below is represented as executed PostgreSQL output.

6. Pause admission and settle transactions without guessing

Process owners stop admission; DBA and business owner settle existing operations. Record each worker's last admitted operation, last known committed operation and disposition of the gap. A queue that is empty at one instant may contain delayed or retried work elsewhere. Name who owns pending messages, in-flight leases, retry timers and scheduled reruns. Pausing the producer and consumer must not silently discard accepted customer work.

For each established session, retain a stable observation tuple such as backend identity, backend start time, role, database and observed transaction interval. Record whether its transaction committed, rolled back, remains active or has an unknown acknowledgement. An operation with a lost client acknowledgement needs state/effect reconciliation by its operation ID before replay. Process exit alone is not evidence that the business operation never committed.

If two-phase transactions are used, include pg_prepared_xacts in the settlement evidence. Prepared transactions are a separate obligation, not simply an ordinary connected session. The transaction owner must decide their disposition; this article provides no blanket commit or rollback command. Verified non-use can be recorded as an exclusion. Unknown use holds the gate.

Do not terminate every idle-looking backend. The DMS source documentation warns that its transactions may be idle and interruption can fail a task. The DBA must distinguish endpoint sessions from application sessions and assess the exact approved action. A broken replication task cannot be accepted as evidence that the application fence worked.

7. Collect three distinct source-rejection receipts

Each writer owner, observed by the evidence reviewer: output current old-session, reconnect and delayed-run results. The old-session attempt uses the already established path within the approved probe contract. The fresh-connection attempt exercises the current admission configuration. The delayed-run attempt uses the scheduler/queue path that might restart after the maintenance window. When a mode genuinely cannot occur, record why and retain evidence of that exclusion.

Repeat the relevant effective-role context, including indirect routine calls and role switching, rather than only testing the default login. Bind every receipt to the control revision. A later grant, release, job definition or connection configuration change invalidates the associated evidence until reviewed and retested. A successful source mutation after the declared fence is a failed gate, even if it is only the team's synthetic probe. Reestablish the final source cut after the approved correction; do not leave the earlier boundary unchanged.

The observer should check source state separately from the client response. A denied client request that delegated work to another process is not necessarily a denied business mutation. Any unexpected write path, missing receipt or inconclusive result leaves that writer held. Maintain the exact denominator and the reasons for exclusions. The ledger records observed scope; it does not discover unknown applications automatically.

Figure 1. Proposed evidence conjunction for each writer. Three receipt modes are not alternatives; transaction settlement and the governed administrative scope remain additional obligations. All evidence in this paper is fictional, not executed database output.

8. Drain capture and apply at the final committed source cut

DMS operator and invariant owner: output final-cut capture/apply evidence plus paired data acceptance. First settle the business-writer boundary. Then establish the final committed source cut using the already rehearsed mechanism for this task and workload. State how the cut maps to the task evidence and target data; do not equate a timestamp or arbitrary PostgreSQL position with a DMS applied checkpoint without a verified mapping.

DMS monitoring separates capture and target-apply latency. Those metrics help diagnose delay, but a zero source-latency value can occur when there are no new events to read. A dashboard showing zero is not a substitute for final-cut inclusion and independent business reconciliation. Retain complete selected-table coverage, task/table status and the agreed paired exports or queries.

If a late source mutation occurs, return to settlement and declare a new final cut. If capture fails, logs become unavailable, target validation remains incomplete or the mapped cut is uncertain, keep target application admission closed. Use the paired-reconciliation playbook for discrepancy treatment. Do not turn this writer ledger into a second data comparator or claim row equality establishes every external effect.

9. Admit target writers in an explicit order

Target DBA and cutover lead: retain the target admission revision and first accepted business operation. The target may already receive DMS apply writes. Here, target admission means enabling the named application paths after the separately rehearsed replication handover and final-cut acceptance, not making a globally read-only instance writable. Record the replication stop/disposition and any configuration changes as distinct evidence.

Handle generated keys before admitting affected writers. AWS documents that ongoing PostgreSQL target replication does not migrate sequence current values. The target DBA must separately verify the approved sequence handover for this workload after replication stops. A matching row count does not resolve that dependency. No universal sequence-setting command is supplied here.

Admit the smallest agreed writer set first. Verify its actual target resource/role, controlled accepted operation and state readback while its old source path remains rejected. Record the first accepted target application write and any associated external-effect identity. Repeat for subsequent writers only while the evidence/control revisions remain current. A route update without a state readback is not an admission receipt. Keep nonadmitted jobs held, with a named owner for resumption or retirement.

Figure 2. Proposed authority handover, not an executed migration. DMS target apply is distinct from application admission. Before-write restoration remains conditional; after the first target write, recovery requires separately accepted history and effect reconciliation.

10. Work through six fictional writers

The specimen represents database orders-A, source alias pg-source-A, target alias pg-target-B and six identified writer processes. Actual versions, account resources and observations are absent. The receipt names below refer to stipulated fictional records, not files captured from an AWS environment.

API revision api-r42, owner application lead. Direct keyed-table mutation is its declared path. The fictional old-session and reconnect receipts are supplied, and the delayed-run mode is excluded through a reviewed no-scheduler record. The transaction receipt settles its final operation. Its row is scoped evidence-complete, not cutover-approved.

Queue worker worker-r17, owner queue lead. The old session and reconnect are rejected in the supplied records, but a delayed retry is unobserved. HOLD. Waiting for the queue's visible count to reach zero does not fill the missing timer/retry receipt. The owner must exercise the approved delayed path and account for pending operation identities.

Nightly importer import-r8, owner data operations. A direct-grant change was recorded, but membership still reaches an update role. The fictional routine/path review identifies the remaining effective authority. HOLD until the DBA approves a correction and the owner repeats the three relevant attempts against the new control revision.

Repair routine caller repair-r3, owner support engineering. The callable SECURITY DEFINER path is included explicitly. The stipulated routine-call rejection, reconnect and transaction receipts cover that path. There is no claim that all other functions in the database were tested.

Deployment migrator deploy-r11, owner release engineering. Its job is disabled but its next deployment trigger has no receipt. HOLD. A screenshot of a disabled job is retained as admission evidence, not reused as proof that a future release cannot invoke the database path.

Break-glass administrator admin-r2, owner database operations. This is a governed exception, not a business writer proved unable to mutate. Its privileges, approved observer reads, write freeze and audit interval need separate sign-off. Any unplanned administrative write invalidates the source cut. The specimen's unsigned exception remains held.

These six records contain two scoped evidence-complete business paths, three held business paths and one held administration exception. Target application admission remains closed. Completing the missing retry/job receipts, removing the inherited path and approving the administrative freeze can advance a new review packet only after actual authorized evidence is collected. The specimen cannot produce that evidence.

11. Fill the reusable writer record

Use one record per process revision and materially different authority path, even when roles are shared. Retain the detailed evidence in an access-controlled store. The following filled record is fictional; the blank record is intended for team completion. Neither authorizes changes.

Filled example: queue worker remains held

Writer and revision

queue-worker / worker-r17

Accountable owner

Queue lead, fictional owner

Database and resource scope

orders-A; pg-source-A to pg-target-B; real identities UNKNOWN

Effective mutation paths

worker-role direct keyed-table path; catalog review reference role-review-Q1

Admission and control revision

Queue intake pause plus DBA-approved control alias fence-Q1

Existing-session receipt

Q-old: stipulated denial and state readback; no actual SQL execution

Fresh-connection receipt

Q-new: stipulated source rejection; no actual connection

Delayed-run receipt or exclusion

MISSING; pending retry timer identified by queue owner

Transactions and accepted work

Q-tx: stipulated disposition of operation op-104; retry intent retained

Final-cut and apply evidence

NOT ESTABLISHED while delayed writer remains unresolved

Target admission and first write

CLOSED; first target application operation absent

Disposition and next action

HOLD; queue lead supplies approved delayed-run evidence before a new cut review

Blank record: retain unknowns rather than assumptions

Writer and revision

Record process identity, release/job revision and distinct authority path.

Accountable owner

Name the owner who can stop, observe and disposition its work.

Database and resource scope

Record actual resource/database/objects privately, plus safe aliases.

Effective mutation paths

Attach direct, membership, PUBLIC, owner and callable-routine review.

Admission and control revision

Describe each separately authorized control and its limitations.

Existing-session receipt

Bind session identity, operation, result and independent state readback.

Fresh-connection receipt

Bind current destination, identity and actual rejection evidence.

Delayed-run receipt or exclusion

Exercise the approved scheduled/retry path or retain a justified exclusion.

Transactions and accepted work

Disposition ordinary/prepared transactions and unknown acknowledgements.

Final-cut and apply evidence

Attach the verified cut mapping, selected-table coverage and paired acceptance.

Target admission and first write

Record separately authorized admission revision and first accepted operation.

Disposition and next action

State HOLD, failed or scoped review-ready, with owner and missing evidence.

The anonymous writer-ledger companion contains this fictional six-writer packet, a reusable worksheet and offline structural assertions. It performs no SQL, provider call or authority decision. Its stipulated status fields are not a computed cutover result.

12. Handle aborts before and after the first target write

Before target application admission, an abort can return work to the source only through the rehearsed recovery plan: verify the target accepted no application writes or effects, restore specific controls under approval, account for paused work and confirm source reconciliation. A failed probe, broken DMS session or exceeded pause budget is a reason to hold, not a reason to improvise a DNS reversal.

After the first accepted target application write, treat recovery as a different state. Keep both histories and operation identities. Contain admissions, determine which effects occurred, and choose separately authorized forward repair or reconciled recovery. This procedure supplies no reverse replication and no stale-source failback. If the source accepted writes while target writers were active, the one-writer assumption failed. Stop claiming the prior final cut is valid and open a dual-history reconciliation incident.

The ledger must survive recovery. Preserve previous revisions, failed/inconclusive receipts, control changes and the reason a new boundary was established. Do not overwrite a failed old-session result with a later favorable reconnect result. They answer different questions and the first failure explains why the control changed.

13. Acceptance checklist and the next evidence review

The cutover lead and independent evidence reviewer should mark every item complete or keep target application admission held:

• The writer denominator includes dormant jobs, old releases, callable mutation paths and governed administrative exceptions.
• Actual versions, resources, configuration revisions and authorized roles are observed; excluded mechanisms remain explicit.
• Each writer has current admission, existing-session, reconnect and delayed-run evidence, or an evidenced exclusion for a mode that cannot occur.
• Ordinary and prepared transactions, unknown acknowledgements and pending accepted work have owned dispositions.
• Every required rejection is tied to the correct source path and independent state readback; timeouts and missing evidence are not passes.
• The final source cut is established after the last permitted mutation, and capture/apply plus paired business acceptance cover that cut.
• Replication and sequence handover are separately accepted before target application admission; DMS apply writes are not confused with application authority.
• The target's first accepted operation, old-path rejection and recovery boundary are retained. No privileged exception is described as permanently unable to write.

For the next review, the application owners should bring one complete writer record and the full unresolved-writer register to the source DBA and cutover lead. Resolve the first missing old-session, reconnect or delayed-run receipt before scheduling target admission. Ampity's cloud migration work can help define that evidence boundary; this paper itself grants no operating authority.