Perhaps anyone at #server has interesting insights on this subject!

I think designing tables in Exposed allow to define a fine-grained database model using Kotlin syntax / type safety. If you want advanced features with your entity API (like multi-column keys, check constraints, indices, cascades, etc.), won't you end up with something very similar to what exist in Exposed ? I think that having an SQL based API allow more control over the storage model (with a counterpart that you might have to write more code/description). An article that (I think) well describe relational model complexity is the Jooq "database first" blog post : https://blog.jooq.org/truth-first-or-why-you-should-mostly-implement-database-first-designs/ Maybe it can help discover bumps on the road ahead.

@Alexis Manin good point and terrific article 👍🏻 I suppose in the end you will end up with a product that will (have to) support the features Exposed supports. I think the friction I am having with it is that for 80% of the tables this fine grained control is not needed, but for these entities you're still required to create the same amount of boilerplate code. I guess my goal with this would possibly be to reduce that