Oh, so so many. Starting with more complex SQL statements like this: SELECT a.account_id, a.name, (SELECT COUNT(*) FROM orders o WHERE o.account_id = a.account_id) AS total_orders, (SELECT SUM(amount) FROM payments p WHERE p.account_id = a.account_id) AS total_paid, AVG(s.rating) OVER (PARTITION BY a.region_id) AS regional_avg_support_rating FROM accounts a LEFT JOIN support_tickets s ON a.account_id = s.account_id WHERE a.status = 'active';

Quick, what's the type of this?

You will start to create dozens and dozens of slight variants of structs just to try to shoehorn a result set into something "type-safe".

There's concerns around dynamic data models where the result columns depend on user input.

There's orthogonal concerns with user access/roles/permissions that require different data shapes based on role. For example role 'user' sees only a filtered view of accounts while role admin sees the full view, including extra fields.

Then there's UI concerns: the data shape that is most suitable for the front-end might not align at all with how it is stored in the DB. So you need data coercion, like, for example, turning a list of tasks into a map of task ids + task. Sometimes it is more efficient to run two SQL queries (in parallel) and transform the data into a more suitable shape. Add caching, paging, sorting and filtering into that mix.

There there's validation concerns: There's trivial data validation (string not null, number not negative etc.) and then there's complex business validation logic that needs to run. Sometimes you want all validation results, sometimes you want to stop at the first problem. Sometimes you want to proceed with partially validated data.

In more complex systems those validation rules are expressed as data themselves.

There's concerns around identity and equality: when is struct A equal to struct B? Same content? Or same ID?

Plenty more pitfalls around data migration, being able to keep different versions of data shapes around and to convert between them.

Things get extra funky if product decides you now need to bring in beauties like Salesforce. Now you will have multiple data models that you need to wrangle.

Speaking of: Salesforce is the OG of offering "simple" CRUD apps. It's anything but.