Introduction

JPQL does not support a SQL LIMIT clause directly inside the query string. Instead, result limiting is controlled through the JPA query API, usually with setMaxResults and optionally setFirstResult for pagination. That separation is intentional because JPQL is an object-oriented query language, while database-specific row limiting is handled by the persistence provider.

Use setMaxResults Instead of LIMIT

The JPQL equivalent of “give me only the first N rows” is:

1TypedQuery<Employee> query = entityManager.createQuery(
2    "select e from Employee e order by e.hireDate desc",
3    Employee.class
4);
5
6query.setMaxResults(10);
7
8List<Employee> employees = query.getResultList();

Here the query string contains no LIMIT, but the API call limits the result size to 10 rows.

This is the standard answer to the question.

Use setFirstResult for Pagination

If you also need an offset, combine setFirstResult with setMaxResults.

1TypedQuery<Employee> query = entityManager.createQuery(
2    "select e from Employee e order by e.hireDate desc",
3    Employee.class
4);
5
6query.setFirstResult(20);
7query.setMaxResults(10);
8
9List<Employee> page = query.getResultList();

This behaves like pagination:

• skip the first 20 rows
• then return up to 10 rows

That is the usual JPQL replacement for SQL patterns such as LIMIT 10 OFFSET 20.

Always Pair Limiting With ORDER BY

A limit without an explicit order is usually a bug waiting to happen. If the query does not specify ORDER BY, the database is free to return rows in whatever order it finds convenient.

So this:

query.setMaxResults(1);

only makes sense if the query also clearly defines which row should count as “first.”

Good:

"select e from Employee e order by e.createdAt desc"

Without ordering, limited results can be nondeterministic across runs or database plans.

The Persistence Provider Translates It

When you call setMaxResults, your JPA provider turns that into the appropriate SQL for the database in use. That is one reason JPQL itself does not hard-code vendor-specific limit syntax.

Depending on the database, the generated SQL might use:

• 'LIMIT'
• 'FETCH FIRST'
• 'TOP'
• or another database-specific construct

The abstraction lets the same JPQL code work across supported databases.

Repository and Framework Variants

If you use Spring Data JPA, this same concept often shows up through higher-level APIs such as:

• 'Pageable'
• derived query methods like findTop10By...

Those conveniences still map down to the same idea: the framework eventually applies result limits through the underlying query API rather than embedding a literal LIMIT keyword into JPQL itself.

Native SQL Is Different

If you write a native SQL query instead of JPQL, then database-specific LIMIT syntax may be perfectly valid.

Query query = entityManager.createNativeQuery(
    "select * from employee order by hire_date desc limit 10"
);

That is not JPQL anymore. It is native SQL, which means portability depends on your database.

So the distinction is:

• JPQL: use setMaxResults
• native SQL: use the database's actual SQL syntax if you want

Common Pitfalls

The first pitfall is trying to write LIMIT directly into JPQL and expecting the provider to accept it. JPQL is not SQL, so that keyword is not part of the language.

Another issue is limiting results without adding ORDER BY. A limit without a defined ordering often produces unstable or meaningless results.

Developers also mix up JPQL and native queries. The right limiting mechanism depends on which query language you are actually using.

Finally, pagination with large offsets can become expensive at the database level even though the JPQL API is simple. API convenience does not remove query-cost concerns.

Summary

• JPQL does not have a LIMIT clause in the query text.
• Use setMaxResults to limit result count.
• Use setFirstResult with setMaxResults for pagination.
• Add ORDER BY whenever limited results need deterministic meaning.
• If you need literal LIMIT, that means you are writing native SQL rather than JPQL.