Ideas behind
the framework.

We used JPA and Hibernate for years and mostly liked them. This is the quieter reason we built a different ORM anyway: 300 tables, and managed entities you cannot pass around without ceremony.

The most concise way to describe a table turns out to be the ultimate carrier of your data, and the contract for querying the entire relation graph. Simplicity is the ultimate sophistication.

An entity in ST/ORM is a plain record: a value with no session and no hidden state. Here is what that buys you across your application, without giving up dirty checking or lazy loading.

The most-googled Hibernate error is not a bug in your code. It is a lazy promise coming due after the session closed, and value entities cannot throw it.

You do not fix N+1 by remembering a fetch clause. You fix it by making loading a decision the code shows you, and one you can assert in a test.

SQL is the one interface every database and every backend engineer already shares. Type it and keep it in view, do not replace it with a second query language.

Entity, Repository, SQL Template. A model you can hold in your head is a model that does not surprise you.

Every entity gets a companion generated at compile time. It makes column and path references type-checked, and it lets queries and hydration run on generated code instead of reflection.

You do not need bytecode enhancement or a session-bound proxy to write only the columns that changed. You need the value before and the value after.

We build in Kotlin, so why not build ST/ORM on JetBrains Exposed? Exposed is excellent at modeling a database. ST/ORM draws the boundary differently: the model stays in the database, and application code gets plain, typed records.

The strongest arguments against ORMs are really arguments against ORMs that hide SQL. Take the concealment away and most of the case dissolves.