When do you use JPQL, native SQL, Criteria API, or Spring Data specifications?

Chooses a query representation from static versus dynamic shape, portability, database features, readability, and performance evidence.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

JPQL queries entities and their mapped attributes, so it is portable across JPA providers and good for clear static entity-oriented queries. Native SQL gives full access to database-specific syntax, functions, windowing, and tuned plans but needs explicit result mapping and reduces portability. The Criteria API builds queries programmatically and is useful for truly dynamic composition, while Spring Data specifications package reusable predicates on top of Criteria.

Full answer below

Practice focus

Entity-oriented queries, database-specific SQL, dynamic predicates, type safety, projections, and maintainability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
The best query form is the clearest one that expresses the required data shape and produces acceptable SQL.
JPQL queries entities and their mapped attributes, so it is portable across JPA providers and good for clear static entity-oriented queries. Native SQL gives full access to database-specific syntax, functions, windowing, and tuned plans but needs explicit result mapping and reduces portability. The Criteria API builds queries programmatically and is useful for truly dynamic composition, while Spring Data specifications package reusable predicates on top of Criteria.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I do not replace a readable fixed JPQL query with a large Criteria tree just for type safety. Derived repository method names work for simple filters but become difficult to read as conditions grow. Projections avoid loading full entities for read-only views. Native queries require tests for parameter binding, pagination or count behavior, column aliases, and migrations. Whatever syntax I choose, I inspect the generated SQL and execution plan for important paths.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using Criteria for every static query.
Assuming JPQL automatically produces efficient SQL.
Allowing unbounded client-driven specifications.

When do you use JPQL, native SQL, Criteria API, or Spring Data specifications?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?