Oracle DBMS - Disable Extensions You Aren't Using

If you're not using Data Miner, or if you're not working on a Migration – disable those extensions! SQL Developer will run leaner & meaner, plus the user interface will be a bit more simplified making the tool easier to navigate as well.

Make it Run Faster!

The 'Holy Grail' of software tools is the environment where things are made easy, but not at the expense of usability or simplicity. You use a tool because it makes something 'easier', but some software products are anything but.

SQL Developer is fairly scaled down. You have a few toolbars, several menus, and 2 driving windows - the Worksheet and the Browser. But what if it could be even simpler? SQL Developer is asked to be the database IDE. We serve many masters, yet a majority of our users simply look to the tool to be a GUI replacement of SQL*Plus.

What if you as a user could 'slim' down SQL Developer? Less menu items, fewer widgets to load? A leaner, meaner SQL Developer?

Well, you can do that today.

Disable Extensions: Versions 1 - 3.2

Go into the preferences and disable all the extensions.

Disable Feature: Versions 4.0 and Higher

On the Tools menu, select 'Features' - and turn off things you don't use. Like Migrations - this is a BIG feature that MOST of you won't need to use.

This looks quite a bit different than before, but it's the same concept.

The Results

Once you make a change here you will need to re-start SQL Developer to make the changes take effect. You will see two primary advantages:

  • Faster load time
  • Simplified UI

Load Times

You should see a faster start time with disabled features - but it depends on your machine and how many of the 'big' features you disable. On my WIN7x64 machine SQL Developer is loading in about 17 seconds with everything turned on, and in 10 seconds with most things off including the Start/Welcome Page. I did leave on the Data Modeler, because I think folks like the 'Model' tab when looking at Tables, and that requires the Data Modeler extension.

For the primary benefit, you will notice the main menu items are skinnier - no items for Source Control, the Data Modeler, Migrations, or Data Miner. These are not 'bad' things, but chances are you rarely use these features. You can in fact turn them off (and turn them on, as required.)

On my Mac - I didn't even try turning things off. I have like a 7 second load time with everything on.

Simplified UI - 'Lite' Mode

Default UI

Further Optimize Your SQL Developer Experience

There are a few more techniques and preferences you can exploit to get SQL Developer running faster and using less system resources. Note that I run SQL Developer 'out of the box' with no tweaks and it runs just fine. However what works for many people won't necessarily be right for everyone. Here are a few changes you can make in a few moments to dramatically affect SQL Developer's performance.

Set Look and Feel Preference to Host OS

Look and Feel is a Java property that controls how the application's GUI 'widgets' are drawn and behave. You can let the host OS control this, or you can implement your own themes. SQL Developer ships with an 'Oracle' Look and Feel theme. I think it's nicer than what Windows gives out of the box for Java applications.


It costs more, CPU to be specific. It takes more work for the tool to run if it's controlling the 'look and feel' instead of just farming that out to the operating system. Now the funny or weird part here is that I've heard a few OS X folks tell me they see the exact opposite behavior. So, if you see SQL Developer running slow or it chewing up the CPU, try switching this preference and restarting the application.

Or if you're on a Mac

Close Grids and Files When You're Done with Them

This is hopefully common sense. Having data loaded in a grid consumes memory. Lots of rows = lots of memory. Close the grids when you're done. When you close a grid it forces the JVM to do garbage collection. This is fancy talk for saying that the java application will release memory back to the java virtual machine. This will also keep your DBAs happy - leaving grids open with un-fetched results (you queried a billion row table but only got the first page) leaves processes and other system resources tied up.

Don't Set Your SQL History Limit to Some Obscenely High Value

Like 30,000. That's too high. I think the default (100) is too low. Mine is currently set to 500. Just know that what you set it to affects memory. The SQL History data is read into memory at start up. The more you save, the more it costs.

Go back