For us, it was basically about using direct SQL to avoid the ORM / SQL mismatch, while still having a (relatively) straightforward way to turn rows into POJOs.

For us, it was basically about using direct SQL to avoid the ORM / SQL mismatch, while still having a (relatively) straightforward way to turn rows into POJOs. I mean, not as easy as just annotating some attributes of a class for Hibernate, but being able to specify the SQL itself was what sold me on it. I guess it's not much different to Spring's JdbcTemplate etc. in that regard, but it came with minimal dependency baggage. I do quite like Jdbi's SqlObject API, wherein you annotate a interface's methods with SQL (and a bunch of other annotations if you're getting fancy) which abstracts the boilerplate away to a large extent. I use this quite often for integration testing where there's an embedded PG instance and you need a straightforward way to populate it with expected data. Where it really shined though, was in stuff that is trivial in SQL, but hard in DSLs, like doing a batch upsert (or as PG calls it, INSERT ... ON CONFLICT DO UPDATE...) was trivial in Jdbi compared to Hibernate etc. Just because we weren't relying on some DSL to generate the necessary SQL. Also, Jdbi integrates reasonably nicely with Flyway schema migrations.