> You have two tables then CUSTOMER and ORDER and you JOIN them. Why not just put the orders inside of CUSTOMER? Because now you can't query it, because you don't know how many columns will come out and you can't have disparate columns across rows.

Why wouldn't you be able to query it? You can query JSON fields that contain lists. Why not SQL fields with strongly typed lists?

> Sure, it's a different way of thinking. But its faster, its MUCH safer, the invariants are actually properly specified.

Why would it be safer?

An embedded list has pretty clear and obvious semantics. And as ekimekim said in another comment, postgres already has partial support. Apparently this works today:

    CREATE TABLE example (
        height number_with_unit, -- our composite type, eg. (6, 'ft') or (180, 'cm')
        known_aliases TEXT[], -- list of string
        active_times TSRANGE, -- time range, ie. (start, end) timestamp pair
    );

An embedded list also sounds much faster to me - because you don't have to JOIN. Embedding a list promises to the database "I'll always fetch this content in the context of the containing record". Instead of (fetch row) -> (fetch referencing key) -> (fetch rows in child table), the database can simply fetch the associated field directly.

> But I wouldn't dare touch a mongo instance without going through the application, because all the constraints are willy-nilly implicitly applied in the application.

Yes, I hate mongodb as much as you do. I want explicit types and explicit invariants. But right now mongodb has useful features that are missing / unloved in SQL. How embarrassing. SQL databases should just add support for this approach to data modelling. Its nice to see that postgres is trying exactly that.

In programming, I don't have to choose between javascript and assembly. I have nice languages like rust with good type systems and good performance. We can have nice things.