Does DataGrip's toolbar Limit control adapt to dialects like SQL Server and Oracle?

Direct answer

Yes — DataGrip's toolbar Limit control is dialect-aware. When you set a value in the Limit input, DataGrip rewrites the executed statement using the row-limiting syntax of the resolved SQL dialect: TOP n for SQL Server, OFFSET 0 ROWS FETCH FIRST n ROWS ONLY for Oracle 12c+, and bare LIMIT n for PostgreSQL/MySQL. It does not blindly append literal LIMIT to every dialect.

How the two controls differ

The Limit input and the Result set page size (fetch size) serve separate purposes:

• Limit (toolbar) — modifies the SQL text before execution, adding a dialect-appropriate row-limiting clause. The default is empty (no limit).
• Result set page size — controls JDBC fetch size (default 500 rows). It only affects how many rows are retrieved per round-trip while scrolling the grid; it never changes the SQL statement.

Because the limit is applied at the SQL-generation layer, the actual statement sent to the server can be inspected in the console output or query log to confirm which clause was generated.

Export dialog pagination

The export dialog's pagination option follows the same dialect-resolution path. On engines that support OFFSET/FETCH or LIMIT, DataGrip rewrites the query for each page. On engines without standard offset/limit syntax (older Oracle, some niche dialects), the behavior depends on whether the resolved dialect provides a rewrite rule — it may skip pagination, fall back to client-side paging, or error. The safest way to know is to test against your specific data source.

When manual pagination is still the right choice

Writing pagination directly in your SQL remains valid and sometimes preferable when:

• The auto-detected dialect is wrong (common with proxies, compatibility modes, or less common engines).
• You need a specific clause the generator doesn't produce (e.g., TOP n WITH TIES on SQL Server).
• You want the statement to be portable across dialects without relying on IDE rewriting.

Verification steps for your workspace

1. Open a query console on a SQL Server data source, set the toolbar Limit to a small value (e.g., 10), run a simple query, and check the executed statement in the console output — look for TOP (10).
2. Repeat on an Oracle 12c+ data source — look for OFFSET 0 ROWS FETCH FIRST 10 ROWS ONLY.
3. Open the data source properties and confirm the SQL dialect field matches the target engine (not "Generic" or "Auto" if auto-detection is unreliable).
4. Test the export dialog's pagination option against a database lacking OFFSET/LIMIT support and observe whether it rewrites, skips, or errors.

One diagnostic detail that changes the recommendation

What SQL dialect is currently assigned to each data source in DataGrip's data source properties? If any show "Generic" or an unexpected dialect, force the correct dialect and re-test — dialect misresolution is the most common cause of invalid limited queries.