The arithmetic on that snapshot is short. One extract taken for a migration in 2019 [2]. Two onward copies, one for load testing and one so a contractor could reproduce a bug [3]. Then the artefact store of whichever tool gets pointed at the environment [9]. Four places holding production-shaped records, with no approval recorded against any of them [19], because copying a dataset does not feel like an act that needs an owner [4]. Production, by contrast, has brokered access, reviewed changes, logged reads, and somebody who owns the log [16].
The generator objection needs its precise form, not the slogan. Synthetic data is built against a schema, and a schema is satisfied by an ordinary customer with three orders [6]. The shapes the post cares about are all legal under that schema and described nowhere in it: 4,000 orders on one account, an apostrophe inside a name, an address with no postcode, a record that arrived through two migrations [5]. A generator can produce those. To make it produce them you first measure the production distribution and encode it, so the useful part of the fixture is derived from production regardless. That is what makes the post's spectrum framing hold up: usefulness and identifiability are being read off the same property, which is why teams settle on a dataset they would not put in a public bucket [7][17].
The tenancy question is where the review gets concrete. "Separate databases" and "a tenant_id column and a WHERE clause" are both answers, and the post is right that they are not the same answer [14]. In the second, separation is one predicate in one query, and every query written afterwards is another chance to omit it. The authorisation failure mode is the same shape at a different layer: one effective permission level, where anyone who can reach a run can read it [12]. Triggering a run against the payments service and reading the payloads that run captured are different privileges, and a role model that cannot split them has not answered the question [13].
This is one post on a company's dev.to account [1], and it carries no measurement: no survey, no incident count, no named estate [20]. The four review categories it enumerates are also a feature list a testing vendor would want to sell against [11]. That does not make the mechanism wrong, and the identity claim is checkable in an afternoon, since a tool with its own user list either does or does not appear in your leaver process [10]. For the rest to transfer, two things have to be true where you work: the fixture descends from a production extract, and the tool persists payloads and screenshots after a failure [8][9]. If fixtures are generated per run and discarded, none of it is about you. I have never seen a screenshot bucket on a data inventory, and it is the store I would check first.
Both answers already exist inside the estate, and the review usually starts with the datasheet instead [18].
