Skip to the content.

ORM or SQL Amplifier?

There is unquestionably a sweet spot where ORMs work well, which is great.

But there are numerous cases where they don’t:

Dependence on a particular DBMS is sometimes raised as a limitation of Wrapd and similar tools, but the DBMS rarely changes during the product lifetime (as noted above) and changing SQL dialects is relatively easy, particularly as Wrapd tests all queries.

Notably, an ORM typically trades a relatively light SQL-dialect dependence for a heavy ORM dependence. Is that really an improvement?

In Wrapd, the build tools are built into the Wrapd library and are trivially and largely invisibly integrated into (for example) Gradle build pipelines. Yes, it benefits from a particular build strategy and project structure, but that’s conceptually no different from typical ORM-based projects and arguably simpler than the configuration files and/or annotations required by some ORMs.

That said, Wrapd and similar SQL amplifier tools aren’t a panacea or a silver bullet — there is no such thing — but for use cases that would either work against ORMs or that would struggle with raw ODBC/JDBC, Wrapd and similar SQL amplifiers are a potent alternative.