[aeyes]

> You don’t just design a good table schema independently and start querying it

This is only true for trivial problems, in the real world you are going to have tradeoffs. You can't design a schema for transactional and analytical workload at the same time, yet every type of business needs some sort of analytics on their data.

The great thing about SQL is that you don't exactly need to know what your future queries are going to look like. Or your dataset.

[Someone]

Yes, you don’t exactly need to know what queries will look like, but I don’t think the GP claimed that.

You need to have a fairly detailed knowledge, though. How are you going to make educated trade-offs if you don’t know what kind of queries will be made, how often, and how important it is they run fast?

That’s why, in evolving programs, the database evolves, too, even if the table content stays 100% the same. Moving some tables to faster storage, splitting them horizontally or vertically, adding or removing indices, compressing or no longer compressing fields, updating statistics more frequently, etc.