1. An Elm-like programming language that lives in .db files
2. A compiler from this language to strongly-typed database procedures in a target backend language
This has more in common with a semantic layer than an ORM.
What you gain is a shared language that connects the table definitions (say a SQL migrations folder) and your API language (often handwritten SQL). This can be type checked and optimized for you.
But for me the big question is what functionality do you lose? Can I express everything that PostgreSQL can?
1. An Elm-like programming language that lives in .db files
2. A compiler from this language to strongly-typed database procedures in a target backend language
This has more in common with a semantic layer than an ORM.
What you gain is a shared language that connects the table definitions (say a SQL migrations folder) and your API language (often handwritten SQL). This can be type checked and optimized for you.
But for me the big question is what functionality do you lose? Can I express everything that PostgreSQL can?