Hey, thanks for the comment!

On 1, that's right, we do need to model the data differently for different use cases. That doesn't necessarily have to be by building transforms on top of the transactional database though (or on a copy of it in a data warehouse or similar) and can be produced closer to the source, either within the application code at write time, or one step below that.

Patterns like outbox and designs like event sourcing help software teams adopt this.

2, yeah that is true. There is always a trade-off, and in this case we are favouring stability and dependability over providing all the data in a raw form that is unstable and difficult to use.

I think in most cases that's a good trade-off, as if we can't put things into production reliably then there's no point experimenting with what we can build 😀 But I do accept that it is a trade-off, and I haven't yet found of a solution that gives us both.