SQL Developer vs SQLcl

sqlcl short The short version

• Browsing schemas, writing PL/SQL, debugging? Oracle SQL Developer. A grid and a debugger are things a terminal cannot give you.
• Running scripts, automating, working over SSH? SQLcl. It starts in a second, needs no display, and scripts cleanly.
• Both. They read the same saved connections, so using one does not mean abandoning the other.

sqlcl what What SQLcl is

SQLcl is Oracle’s replacement for SQL*Plus: the same command-line model, with the rough edges removed. It understands SQL*Plus commands and scripts, so existing work carries over, but adds command history, tab completion, inline editing and output formats that SQL*Plus never had.

It is a Java application like Oracle SQL Developer and needs the same JDK 17 or newer, but the download is around 20 MB against several hundred — because there is no interface to ship.

sqlcl when Where SQLcl is the better tool

• Headless servers. Oracle SQL Developer needs a display; over a plain SSH session it simply cannot run. SQLcl is the answer there, not a workaround.
• Automation and CI. Scriptable, exits with a status code, no clicking.
• Large exports. Spooling a few million rows to a file avoids the memory problems a GUI grid runs into.
• Fast one-off checks. Starting SQLcl is near-instant; the desktop application takes noticeably longer.
• Constrained machines. A 20 MB download and a much smaller memory footprint.

sqlcl when not Where the desktop application still wins

Anything visual or exploratory. Browsing an unfamiliar schema, reading an execution plan, stepping through PL/SQL with breakpoints, comparing two result sets side by side, building a model — these are what a desktop tool is for, and no terminal client substitutes for them.

The honest split is that SQLcl is better when you already know what you want to run, and Oracle SQL Developer is better when you are working out what to run.

sqlcl getting Getting SQLcl

SQLcl downloads from Oracle’s site as a zip, the same way Oracle SQL Developer does, and needs no account. Unzip it, put the bin directory on your PATH, and run sql — there is no installer and nothing is registered system-wide.

• Connect with a saved connection: sql -name my_connection
• Connect directly: sql user/password@host:1521/service
• Run a script and exit: sql user@db @script.sql
• Check it works: sql -version

It needs the same JDK 17 or newer as the desktop application, so if you have already sorted Java out for Oracle SQL Developer there is nothing further to install.

sqlcl limits What you give up

• No debugger. Breakpoints and step-through are desktop-only, and this is the biggest single gap for PL/SQL work.
• No object browser. You query the data dictionary instead, which is fine when you know the schema and slow when you do not.
• No visual plans. Execution plans come back as text rather than an explorable tree.
• No modelling or migration tooling. Those live only in Oracle SQL Developer.

sqlcl formats Output formats worth knowing

The feature that most often converts people is SET SQLFORMAT. SQLcl can emit a result set as CSV, JSON, XML, an ANSI-console table or an inserts script, without any of the export dialogs the desktop application uses — which makes it genuinely useful for pulling data out of a database on a schedule.

• SET SQLFORMAT csv — comma-separated, straight to a file with SPOOL.
• SET SQLFORMAT json — for feeding another tool.
• SET SQLFORMAT ansiconsole — auto-sized columns, far more readable than SQL*Plus defaults for interactive use.
• SET SQLFORMAT insert — emits INSERT statements, handy for moving a small table between environments.

None of this needs a display, so the same command works over SSH as on your own machine — which is the practical reason SQLcl ends up in automation even for people who prefer a desktop client day to day.

sqlcl carry What carries over

• Connections. SQLcl can read the connections you already saved in Oracle SQL Developer, so there is nothing to set up twice.
• SQL and PL/SQL. Identical — same database, same parser.
• SQL*Plus scripts. Run unchanged in SQLcl.
• The JDK requirement. Both need Java 17 or newer, so a machine set up for one is set up for the other.

That shared foundation is why treating this as a choice is usually a mistake. Installing SQLcl alongside costs 20 MB and gives you the option; see the download page for the desktop build if you do not have it yet.