[mccanne]

Author here. All good points. Yes, you can build a super-structured type system on top of tables. EdgeDB does this well. And you can put JSON into relational columns. Then you might ask what the "type" of that column is? Well, if you want deep types, the row type varies from column to column as the JSON values vary and you have to walk the JSON to determine the type. SQL implementation are beginning to try to do deal with this mess by adding layers on top of tables. We're saying, maybe we should think differently about the problem and build tables on top of types as a special case of a type system. This also gives a very nice way to get data into and out of systems without having to go through the messiness of ODBC and special casing tables vs tuples vs scalars etc.

[cryptonector]

Normalize to the max then denormalize till you achieve the performance trade-offs you want. That's the rule in relational schema design.

Adding JSON traversal operators and functions helps a lot when you end up denormalizing bits of the schema. It's not hard.

[vosper]

You mentioned EdgeDB in the blog post, too, but I just think you and them are dealing with different problems.

My understanding of EdgeDB is they're mostly trying to make correct data-modeling simpler and more intuitive; to let people model relations in the same way they speak and think about it, rather than having to map to SQL concepts like join tables. I rather like what they're going for, though I haven't used it.

EdgeDB seems to be mostly for business logic and OLTP. They're not trying to deal with arbitrary incoming data that might be outside of the control of the ingestion system. You wouldn't even have an ingestion system with EdgeDB.

[mamcx]

This is true and is a limitation of SQL (not of the relational model per-se), and also is part of the problem that SQL is not composable (so you don't have a way to nested table definitions)