Following up on a chat with @Jakob_WMDE about this task, some thoughts on two of the open points in the description: which statements to store ("all statements, or only a subset"), and the updating logic (currently TBD).

On the subset question, one natural candidate subset is "truthy" statements, i.e. the best-rank statements per property that wdt: exposes in RDF, since many consumers only ever want those. But truthiness is awkward for a table like this, whether it is used to pick the stored subset or filtered at query time, because it is not a property of a single row but of the (subject, property) group: preferred if any, else normal, deprecated never (the StatementList::getBestStatements() semantics). No encoding of rank on a single row can make that a clean WHERE clause. Suggestion: store rank for every statement (the prototype already does, see the schema and the writer) and have the updating logic maintain a denormalized is_best flag, recomputed for the affected (subject, property) group on write. RDF output already ships this dual encoding (wdt: triples plus wikibase:BestRank), and both RDF builders carry a FIXME about each recomputing best-per-property independently (TruthyStatementRdfBuilder, FullStatementRdfBuilder), so precomputing it once at write time has precedent and a known pain point it would relieve.

On how much of the subset question needs answering up front: mostly none of it. The population scripts are re-runnable, so "which statements to store" (truthy only, certain value or data types, items only) can start narrow and be widened later, as long as the schema does not change. The updating logic is the one decision that does not backfill: with delete-and-reinsert (what the prototype currently does: SecondaryStatementStoreWriter.php), anything about when or how a row changed is unrecoverable after the fact. So of the TBDs in the description, is that the one worth settling deliberately in the acceptance criteria?