Why Java Data Access Is Moving Past ORM: From dbVisitor to JdbcClient

The dbVisitor Hype

Last week a popular post on Open Source China praised dbVisitor, a framework that claims "One API Access Any Database" by providing a single entry point for MySQL, MongoDB, Elasticsearch, Redis and more. The author’s first reaction was skepticism: "Again?" and a question of whether we really need another wheel.

Uniformity Brings Complexity

dbVisitor’s vision is attractive—hide the differences between ORM and client libraries behind one API. In practice, however, the abstraction incurs costs. When a feature like Elasticsearch aggregation or Redis atomic operations is needed, developers must "unwrap" to the underlying driver, as the framework itself admits.

"When the unified API cannot satisfy special needs, dbVisitor allows an unwrap mechanism to penetrate to the underlying driver."

Thus, the promised uniformity works for simple cases but falls back to low‑level code for complex scenarios.

Another Path: Making ORM Excellent

Instead of chasing universality, some projects focus on perfecting ORM for relational databases. Jimmer, described as "the most advanced JVM ORM", solves classic pain points: it eliminates N+1 queries with compile‑time SQL DSL, automatically diffs object graphs to update only changed fields, and generates entity implementations from interfaces.

List<Book> books = sqlClient
    .createQuery(table)
    .where(table.name().like("Java%"))
    .select(
        table.fetch(
            Fetchers.BOOK_FETCHER
                .allScalarFields()
                .store(Fetchers.BOOK_STORE_FETCHER.name())
        )
    )
    .execute();

Jimmer’s approach requires learning a new DSL, annotations, and a different mental model, but it delivers a tighter ORM experience.

Is ORM Still Worth It?

ORMs have long provided value in engineering contexts: a unified API eases team collaboration, standardizes code style, and abstracts transaction management, connection pools, and caching. Ten years ago these benefits were decisive.

However, as AI tools generate perfectly formatted SQL, the extra abstraction layer can become unnecessary overhead. The article argues that when AI can produce consistent, performant SQL, ORM‑specific APIs may act as a redundant "middleman".

JdbcClient: Minimalist Data Access

Spring Boot 3.2 introduced JdbcClient, a lightweight JDBC wrapper that is not an ORM nor a full framework. It lets developers write raw SQL directly in code without separate mapper interfaces or XML files.

// MyBatis style
@Mapper
public interface UserMapper {
    @Select("SELECT * FROM sys_user WHERE username = #{username}")
    SysUser findByUsername(String username);
}

SysUser user = userMapper.findByUsername("lengleng");

// JdbcClient style
SysUser user = jdbcClient
    .sql("SELECT * FROM sys_user WHERE username = :username")
    .param("username", "lengleng")
    .query(SysUser.class)
    .optional()
    .orElse(null);

JdbcClient eliminates the need for separate mapper files, keeps SQL close to the call site, and works seamlessly with AI‑generated queries, reducing cognitive load and improving developer experience.

Conclusion: In the AI Era, the Best ORM Is No ORM

The article concludes that as AI flattens the difficulty of writing SQL, the most effective data‑access strategy may be to avoid ORM altogether and use simple, expressive tools like JdbcClient.