Build1 distinct publisher3 min readPublished
Terraform applies the repository, not your merge request, so deploy duty means carrying a neighbouring team's encryption flag into a resource that has no in-place path for it; the disclosure sits on line 267 of a 427-line plan.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The unit of apply is the queue. Whoever deploys next carries everything merged since the last run, reviewed or not, because their change is the one going out [24]. On this resource that means two real input changes arriving together: a version bump, and somebody else's encryption flag [2][4].
The two interact, and not in the forgiving direction. Aurora refuses a 14-to-15 jump unless `allow_major_version_upgrade = true`, and this config does not set it, so the version bump on its own would have died at apply with an error naming the exact problem [6]. Encryption has no in-place path on an RDS cluster, so Terraform's only available move is destroy and create [5]. A created cluster starts life at 15.4, so the upgrade flag is never consulted [7]. The change that made the deploy destructive is the same change that removed the error which would have stopped it.
Then the reading problem. The replacement notice is at line 267 [1]. The summary arrives 153 lines later [9], which puts it at line 420 of 427 [18]. Inside the block, five attributes carry a tilde, three of them known-after-apply churn on `arn`, `cluster_resource_id` and `id`, leaving two actual inputs [22]. Another 29 unchanged attributes are hidden [15], so the deciding attribute is one of 34 on that resource [21]. The only plain English in the whole plan that tells you the database goes away is the trailing comment, `# forces replacement` [2].
The summary line cannot carry the review. It counts actions rather than resources, a replacement lands as one destroy plus one add [11], and a pipeline that recycles spot workers on every run prints the same shape as one about to drop a database [10]. "3 to destroy" is a count of tombstones with no names on them.
Comparing stacks against each other teaches nothing. On the run in the dev.to writeup, network printed one change, app-services five actions, data-platform seven [12]. Compare each stack to itself and the picture inverts: app-services has printed four to six actions on every run this month, always three adds, never a destroy [13], while data-platform has printed one to three and had never destroyed anything [14]. Seven is about 2.3 times its previous worst day [20].
The author says he rebuilt the scenario on real AWS and it behaves as described [16]. I would treat the two halves of that differently. The RDS behaviour transfers, because it is a service constraint rather than a fact about his workload. The baselines do not transfer unless your stacks are as dull as his: narrow action ranges, destroys genuinely rare, and plan output retained per stack long enough for a range to exist.
The cost is the honest part. That project emitted 6,726 lines of plan output across 30 runs [17], roughly 224 lines a run [19]. Making the plan the reviewable artifact means a human reads that, or something diffs it for them. In my context the rule that pays is narrower than full review: an explicit acknowledgement for any plan line containing `forces replacement`, and each stack's summary diffed against its own last applied run rather than its neighbours. Nobody in this story was negligent [23], which is the least useful sentence available to put in an incident review.
Ranked by verification strength, evidence, and original report placement.
Line 267 of a 427-line Terraform plan reads "# aws_rds_cluster.reporting must be replaced", followed by a -/+ resource block for aws_rds_cluster.reporting.
In that plan block, engine_version changes from "14.9" to "15.4" and storage_encrypted changes from false to true, with the trailing comment "# forces replacement" on the storage_encrypted line.
The merge request says "bump reporting Postgres to 15.4"; the plan does exactly that, and also destroys the reporting database and creates an empty one in its place.
The storage_encrypted change was not the deployer's; someone on another team that shares the repo merged it earlier in the week.
There is no in-place path from unencrypted to encrypted on an RDS cluster, so Terraform's only move is destroy and create, which is what -/+ denotes.
Going from Postgres 14 to 15 is a major version upgrade, and Aurora refuses it unless the config sets allow_major_version_upgrade = true; this config does not set it, so that MR by itself would have failed at apply with an error naming the exact problem.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
The three AWS defaults on your bill that nobody actually chose1 distinct publisher
build
The middle tier for Postgres: own kernel, no public IP, and you own the backups1 distinct publisher
build
Send kills, not scores: the leaderboard fix that turns anti-cheat into a schema decision1 distinct publisher
build
Two mechanisms, one vCPU floor: why db.t3.micro cannot meet a 1-second RPO on RDS1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Plan quoted, histories asserted
The part that carries the argument is quoted rather than summarised: the -/+ block, the "forces replacement" comment on storage_encrypted, and all three stacks' summary lines are printed in full, and the Aurora rule about allow_major_version_upgrade is provider behaviour any reader can confirm without trusting the author. The weaker half is the half that makes it a warning — "four to six actions all month, never a destroy" is recollection about a demo project, no prior run output is shown, and the real-AWS rebuild the piece leans on trails off past the end of the text available here.
Nothing here to count
This is a scenario walkthrough on a project the author built, so there is no release, deployment, or user base to observe. The single run outside the demo is his own AWS rebuild — a test he performed, not evidence that anyone else's pipeline works this way or has been changed because of it.
Undersold rather than oversold
The headline promises one plan line and the piece delivers one plan line, with the strongest assertion in it — that the encryption flag deleted the loud apply-time error which would have forced a second look — also being its most mechanically checkable. If anything it undersells its own reach: nothing in the failure is specific to a reporting database or this pipeline, and any repository shared by two teams with a queue-based deploy has the same shape. dev.to states that scope only obliquely, and the flourish that the summary is "a checksum, not a review" is earned by the counting example right before it.
Reputation, plus a sequel flagged
No product is being sold, no vendor is quoted, no benchmark is being won; what is on offer is craft credibility, plus an explicit trailer for a follow-up on the action-counting problem — the ordinary economics of a serialised engineering blog. The one thing to hold at arm's length is that both the plan and the run history come from a project the author controls, which lets the numbers land exactly where the argument needs them.
Mechanism solid, particulars unaudited
Confidence splits down the middle of the piece. That an unencrypted RDS cluster cannot be encrypted in place, and that a from-scratch replacement never touches the major-version gate, hold regardless of who is telling you. That data-platform had never printed a destroy before this run cannot be checked at all — and it is the pivot of everything after the plan excerpt. One publisher, one author, one project he built himself.