How to Speed Up Oracle SQL Developer: Safe Performance Tuning

Oracle SQL Developer can feel slow in several completely different ways. It may take too long to start, the editor may pause while typing, the Connections tree may load objects slowly, result grids may consume excessive memory, or a SQL statement may simply take too long inside the database.

These problems must not be treated as one issue.

Increasing the Java heap cannot repair an inefficient execution plan. Disabling an extension cannot fix a slow network connection. Adding random JVM flags copied from an old forum post may now prevent SQL Developer from starting because current releases use Java 17.

This guide provides a safe tuning process for Oracle SQL Developer 26.2. It begins with diagnosis, removes obsolete configuration advice and applies only changes that address a specific bottleneck.

SQL Developer performance: identify the actual problem first

Use this table before changing any settings.

My preferred tuning order is:

1. Update SQL Developer.
2. Remove obsolete JVM flags.
3. Separate client performance from SQL performance.
4. Disable only unused features.
5. Increase memory only when there is evidence of memory pressure.
6. Reset the user profile only after exporting connections and settings.

Important 2026 update: remove old Java tuning flags

SQL Developer 26.2 requires Java 17. The Windows x64 download is available with an included JDK 17, while the no-JRE package requires a compatible local JDK 17. Oracle released SQL Developer 26.2 on July 14, 2026.

Many older SQL Developer tuning guides contain options intended for Java 6 or Java 7. These options are no longer suitable.

Remove entries such as:

AddVMOption -XX:MaxPermSize=1024M
AddVMOption -XX:+UseStringCache
AddVMOption -XX:+UseCompressedStrings
AddVMOption -XX:+AggressiveOpts
AddVMOption -XX:+UseConcMarkSweepGC
AddVMOption -XX:+UseParNewGC
AddVMOption -XX:+CMSIncrementalMode
AddVMOption -XX:+CMSIncrementalPacing
AddVMOption -XX:CMSIncrementalDutyCycleMin=0
AddVMOption -XX:CMSIncrementalDutyCycle=10

MaxPermSize belongs to the old permanent-generation memory model and has not been relevant since Java 8. The Concurrent Mark Sweep garbage collector and its associated options were removed from OpenJDK.

Do not replace them with another long collection of undocumented JVM options. Modern Java already selects suitable defaults for a desktop application in most cases.

The only common memory option that may be useful is a deliberately chosen maximum heap size:

AddVMOption -Xmx2048M

Even that should be added only when the existing heap is insufficient.

Step 1: install the current SQL Developer release cleanly

Updating is the first performance and security measure.

Do not unzip the new release over an existing SQL Developer directory. Oracle explicitly recommends extracting it into a new folder. This avoids retaining old libraries, extensions or configuration files inside the program directory.

A clean Windows installation could use:

C:\Tools\sqldeveloper-26.2\

Keep the previous installation temporarily until connections and preferences have been verified.

Recommended update process

1. Export your database connections.
2. Close every SQL Developer window.
3. Download the current x64 package with the bundled JDK.
4. Extract it into a new directory.
5. Start the new executable.
6. Initially avoid importing every old preference automatically.
7. Test startup, one database connection and one worksheet.
8. Import only the settings you still need.

The bundled-JDK package removes uncertainty about which Java installation SQL Developer is using. This is particularly useful on systems with several Java versions.

Step 2: back up connections before changing anything

Before modifying configuration files or resetting the profile:

1. Right-click Connections.
2. Select Export Connections.
3. Choose the required connections.
4. Decide whether passwords should be exported.
5. Protect the export file appropriately.

Saved passwords and connection exports can contain sensitive information. Do not store an unprotected export in a shared folder, source-code repository or cloud-synchronised directory.

Also copy any important:

• user reports,
• snippets,
• code templates,
• SQL history,
• formatter settings.

Oracle stores most user-specific information outside the installation directory so that it survives a normal application update.

Step 3: measure startup before opening a database

A database connection is not required to test application startup.

Close SQL Developer completely, start it and measure the time until the interface becomes responsive.

Then compare:

• startup with no restored worksheets,
• startup after closing unused windows,
• startup with automatic update checks disabled,
• startup with optional extensions disabled,
• startup with a clean user profile.

This isolates the desktop application from database, network and authentication delays.

My practical benchmark

The exact number of seconds is less important than repeatability.

Perform the same cold-start test three times after a Windows restart. A single launch may be distorted by antivirus scanning, disk caching or an update process.

Step 4: disable only optional features you do not use

SQL Developer implements many functions as extensions. Oracle allows optional extensions to be disabled, and the changes take effect after a restart.

Open:

Tools > Features

Depending on the installation, optional components may include functions for:

• migrations,
• version control,
• Data Miner,
• TimesTen,
• unit testing,
• selected third-party database support,
• specialised administration functions.

Do not disable a feature merely because its name is unfamiliar. Disable one group at a time and restart SQL Developer.

Oracle also notes that automatic extension-update checks can increase startup time. Updates can instead be checked manually.

A practical configuration is:

Automatic update check at startup: Off
Manual update check: Regularly

This improves startup predictability without abandoning updates.

Step 5: use conservative memory settings

More heap does not automatically make SQL Developer faster.

An unnecessarily large heap may:

• reserve more address space,
• increase garbage-collection work,
• hide a problem caused by excessive result sets,
• leave less memory for the database, browser and other tools.

Increase the heap when SQL Developer:

• reports OutOfMemoryError,
• fails during a large export,
• handles several large worksheets,
• opens large PL/SQL packages,
• works with large result grids or LOB values.

Conservative starting values

These are practical starting points, not universal Oracle requirements.

Start with:

AddVMOption -Xmx2048M

Do not set a large -Xms value unless a measured use case requires it. Leaving the initial heap at its default allows Java to grow the heap according to actual demand.

Where to set the heap

In a standard extracted Windows package, the relevant application configuration is normally located below:

<installation>\sqldeveloper\bin\sqldeveloper.conf

Depending on how the archive was extracted, the full path may appear as:

C:\Tools\sqldeveloper-26.2\sqldeveloper\bin\sqldeveloper.conf

Create a backup of the file before editing it.

Oracle documents AddVMOption -Xmx... in this configuration for memory-intensive export cases.

After changing the value:

1. save the file,
2. close all SQL Developer processes,
3. restart the application,
4. repeat the same workload,
5. undo the change if there is no measurable benefit.

Step 6: reduce SQL History instead of deleting useful code randomly

SQL Developer stores executed worksheet statements in SQL History. Oracle provides a configurable SQL History Limit under the Worksheet preferences.

Open:

Tools > Preferences > Database > Worksheet

Locate:

SQL History Limit

A useful range for most users is:

500 to 2,000 statements

A developer who relies heavily on history may choose a larger value. The correct limit is not a universal number.

Use:

View > History

or press:

F8

to inspect and clear obsolete entries.

Important SQL should not exist only in the history. Save reusable statements as version-controlled .sql files.

For practical Oracle examples, the following internal guides are more suitable than relying on temporary history entries:

• Return a value when an Oracle SQL query finds no rows
• Differences between NVL, NVL2 and COALESCE
• Recovering data with Oracle Flashback Query

Step 7: reduce editor analysis when typing becomes slow

A responsive application can still have a slow code editor.

Completion Insight analyses the current context and offers object names, columns and syntax suggestions. On large worksheets, complex schemas or slow connections, this may create visible pauses.

Open:

Tools > Preferences > Code Editor > Completion Insight

Test one of these changes:

• increase the activation delay,
• disable automatic invocation,
• keep completion available only when manually requested.

Oracle documents that Completion Insight can be delayed or disabled in this preferences section.

Do not immediately disable every code-analysis feature. First test the editor with:

1. a new empty worksheet,
2. a small SQL file,
3. the large file that causes the delay.

If only one unusually large file is affected, split it into smaller scripts rather than weakening the editor globally.

Step 8: close unused tabs before exiting

SQL Developer may restore open files and interface state during the next launch. A workspace containing many worksheets, object editors, reports and result grids requires more work to reconstruct.

Before closing the application:

• save required SQL files,
• close old result tabs,
• close object-detail windows,
• close disconnected worksheets,
• remove unused report panes.

My preferred rule is to keep active work open but save completed work as files. SQL Developer should not serve as a permanent archive of dozens of unsaved worksheets.

Step 9: avoid massive result grids

One of the most common apparent SQL Developer performance problems is simply excessive output.

This statement may force the database, network and client to process an unnecessarily large volume of data:

SELECT *
FROM large_table;

Use a targeted query:

SELECT
    customer_id,
    customer_name,
    status
FROM customer
WHERE status = 'ACTIVE'
FETCH FIRST 200 ROWS ONLY;

During development, restrict the data before removing the limit for the final process.

Avoid loading large columns unless required:

SELECT
    document_id,
    created_at
FROM documents
WHERE created_at >= DATE '2026-01-01';

Do not include a multi-megabyte CLOB or BLOB column only to verify row existence.

SQL Array Fetch Size

SQL Developer provides an SQL Array Fetch Size setting under:

Tools > Preferences > Database > Advanced

It controls the maximum number of rows fetched into the grid at one time.

Increasing it can reduce network round trips on a high-latency connection, but it can also increase client memory consumption. It does not improve the database execution plan.

Change it only after comparing:

• time until the first rows appear,
• time until all requested rows are fetched,
• SQL Developer memory consumption,
• network latency.

Step 10: distinguish Execute Statement from Run Script

SQL Developer offers two commonly confused execution modes.

Execute Statement

Usually triggered with:

Ctrl + Enter

This executes the current statement and displays a result grid.

Use it for:

• interactive queries,
• examining rows,
• sorting or filtering a result grid,
• checking one statement.

Run Script

Usually triggered with:

F5

This executes the content through the script runner and writes text output.

Use it for:

• multiple statements,
• SQL*Plus-compatible scripts,
• deployment scripts,
• spool-style output,
• reproducible script execution.

A text-based script output can be more appropriate than constructing an interactive grid containing hundreds of thousands of rows.

Step 11: use the correct tool for large exports

SQL Developer is convenient for modest exports, but an interactive GUI is not always the best tool for moving large data volumes.

Use:

• XLSX rather than legacy XLS when a spreadsheet is necessary,
• CSV for simple data exchange,
• SQLcl for scripted extraction,
• Data Pump for large Oracle data movement,
• database-side jobs for recurring exports.

Do not increase the Java heap repeatedly to make a multi-million-row spreadsheet export barely complete. That treats the symptom instead of selecting an appropriate export method.

Oracle specifically recommends XLSX instead of XLS when possible for large spreadsheet exports.

Step 12: test whether the database is actually slow

A slow SQL statement is usually not a SQL Developer tuning problem.

Run a minimal connection test:

SELECT 1
FROM dual;

Then test the actual statement in another Oracle client, such as SQLcl.

Interpret the result:

For SQL performance analysis, inspect the actual execution plan rather than changing the Java heap.

A typical starting point is:

SELECT *
FROM TABLE(
    DBMS_XPLAN.DISPLAY_CURSOR(
        NULL,
        NULL,
        'ALLSTATS LAST'
    )
);

This requires the statement to have been executed with the relevant statistics and the user to possess the necessary privileges.

Potential database-side causes include:

• missing or unsuitable indexes,
• stale optimizer statistics,
• implicit datatype conversions,
• functions applied to indexed columns,
• poor join cardinality estimates,
• blocked sessions,
• database links,
• excessive result volumes,
• slow storage or overloaded database servers.

Step 13: diagnose connection and object-tree delays

If the application opens quickly but connecting or expanding objects is slow, inspect the path between SQL Developer and the database.

Check:

• VPN latency,
• DNS resolution,
• proxy or firewall inspection,
• Oracle listener response,
• TNS alias resolution,
• authentication method,
• database load,
• remote database links,
• object counts in very large schemas.

Compare these connection methods where applicable:

TNS alias
Host / port / service name
Cloud wallet
SSH or VPN path

Do not publish credentials, wallet files or connection descriptors while troubleshooting.

A connection that is slow only on a corporate VPN is unlikely to be repaired by changing -Xmx.

Step 14: test a clean SQL Developer profile

User preferences can become damaged or retain years of migrated settings.

Oracle stores the Windows profile under a version-specific directory similar to:

C:\Users\<username>\AppData\Roaming\SQL Developer\system<version>

On Linux and macOS, the typical location is:

~/.sqldeveloper/system<version>

Oracle documents these locations and explains that deleting the current version folder causes SQL Developer to create a new profile and offer migration again.

Use a safer rename rather than immediate deletion:

system26.2...  ->  system26.2..._backup

Procedure:

1. Export connections.
2. Close SQL Developer.
3. Confirm no SQL Developer process remains.
4. Rename the current system... directory.
5. Start SQL Developer.
6. Do not migrate old settings initially.
7. Test startup and editor performance.
8. Import only required connections and preferences.

If the clean profile is substantially faster, the problem lies in the previous user configuration rather than the application binaries.

Step 15: keep SQL Developer on a local SSD

Application files, user preferences and working scripts should normally reside on local storage.

Avoid placing the SQL Developer installation or active user profile on:

• a slow network share,
• a disconnected mapped drive,
• an aggressively synchronised directory,
• removable media.

Real-time security software can legitimately scan Java archives and newly extracted executables. Do not disable endpoint protection. In a managed environment, request a reviewed exclusion only when monitoring proves that security scanning is the bottleneck and organisational policy permits it.

Changes that usually provide the greatest benefit

My practical priority list is:

1. Clean update with bundled JDK 17

This removes incompatible Java versions, old program libraries and unsupported flags.

2. Removal of obsolete JVM options

This prevents errors and restores Java’s supported defaults.

3. Reduction of result-set size

This improves database work, network transfer and client memory simultaneously.

4. Disabling unused optional extensions

This can improve startup without changing database behaviour.

5. Completion Insight adjustment

This targets editor pauses without disabling useful database functions.

6. Clean user profile test

This identifies migrated preference or cache problems that ordinary tuning cannot resolve.

7. Conservative heap increase

This helps only when memory pressure is the demonstrated cause.

Recommended baseline configuration

For a Windows workstation with 16 GB or more RAM:

SQL Developer: Current supported release
Java: Bundled JDK 17
Maximum heap: 2048 MB initially
Obsolete GC flags: None
Automatic extension update check: Disabled at startup
SQL History Limit: 500–2,000
Completion Insight: Delayed or manually triggered if necessary
Open tabs at shutdown: Only active work
Large exports: CSV, SQLcl or Data Pump

Example configuration entry:

AddVMOption -Xmx2048M

Do not copy the following old configuration:

AddVMOption -XX:MaxPermSize=1024M
AddVMOption -XX:+UseConcMarkSweepGC
AddVMOption -XX:+UseParNewGC
AddVMOption -XX:+CMSIncrementalMode

Troubleshooting checklist

Work through these items in order:

• SQL Developer is the current supported release.
• SQL Developer runs with JDK 17.
• The new release was extracted into a clean directory.
• Old MaxPermSize, CMS and ParNew flags were removed.
• Connections were exported before profile changes.
• Startup was measured without connecting to a database.
• Unused optional extensions were disabled individually.
• Automatic update checking at startup was disabled.
• Old result grids and worksheets were closed.
• SQL History has a reasonable maximum.
• Completion Insight was tested with a longer delay.
• Large queries were tested with a row limit.
• LOB columns were removed from diagnostic queries.
• The same SQL was tested in SQLcl.
• Network and VPN latency were considered.
• A clean SQL Developer user profile was tested.
• Heap size was changed only after identifying memory pressure.

Frequently asked questions

Why is Oracle SQL Developer so slow to start?

Common causes include restored tabs, automatic update checks, optional extensions, migrated settings, antivirus scanning and an old or damaged user profile. Measure startup without opening a database before investigating the database connection.

Should I increase SQL Developer memory?

Increase the heap only when SQL Developer encounters memory pressure, large exports, large files or result grids. A reasonable initial maximum for a workstation with 16 GB RAM is often 2 GB.

Should I set both Xms and Xmx?

Usually only Xmx needs to be adjusted. A large Xms forces SQL Developer to begin with a larger heap even when it is not required.

Is 4 GB heap better than 2 GB?

Not automatically. Four gigabytes may help demanding exports or several large object editors, but it does not make an inefficient SQL query faster.

Where is the SQL Developer configuration file?

In a standard extracted installation, the main application configuration is located below the sqldeveloper\bin directory and is normally named sqldeveloper.conf.

Can I still use MaxPermSize?

No. The old permanent-generation memory model is obsolete. Do not use -XX:MaxPermSize with current SQL Developer and Java 17.

Can I still use the CMS garbage collector?

No. CMS and its associated options were removed from modern OpenJDK releases.

Why is a query fast in SQLcl but slow in SQL Developer?

SQL Developer may be spending time building the result grid, fetching additional rows, displaying LOB values or running editor and interface features. Compare the time to first row with the time required to fetch the complete result.

Does increasing SQL Array Fetch Size improve SQL performance?

It may reduce client-server round trips, particularly over a high-latency network. It does not improve the database execution plan and may increase client memory usage.

How many SQL History entries should I keep?

There is no universal limit. A range of 500 to 2,000 is sufficient for many users. Reusable SQL should be saved in files rather than retained only in history.

How do I reset SQL Developer without losing connections?

Export the connections, close SQL Developer and rename the version-specific system... profile directory. Start SQL Developer with a clean profile and import the connections afterwards.

Should I disable antivirus software?

No. Test whether scanning is responsible and follow organisational security policy. Use a reviewed exclusion only when it is justified and approved.

Conclusion

The safest way to speed up Oracle SQL Developer is not to add more JVM flags. It is to determine which part is slow.

A modern baseline consists of SQL Developer 26.2, JDK 17, a clean installation directory and no obsolete garbage-collector options. Startup problems should be addressed through extensions, update checks, tabs and the user profile. Editor lag should be investigated through Completion Insight and file size. Result-grid problems require smaller datasets or a more suitable export method. Slow SQL must be analysed inside the database.

My preferred configuration is deliberately simple: current release, bundled JDK, 2 GB maximum heap as an initial ceiling, a controlled SQL History limit and no copied Java flags from pre-Java-8 tuning guides.

Further Oracle SQL examples are available in the Blogofant Education section.