I had a question the other day that constantly pops up on my feed whether it’s on social media or people asking Q&A at a conference etc. And that question is “What is the best tool I should be using for my database management and app development?”
And it’s fair to say I generally get a fair bit of pushback when the reply I give is “All of them!“. I get accusations like “You’re just being politically correct and you are towing the Oracle line“, “You’re never going to criticize any of the tools” and so on. But that is definitely not the case.
The reason I say all of them is to reinforce the fact that the moment you decide that there should be a tool that should be always considered the best and should be used exclusively ahead of all others, then you’re painting yourself into a bit of a corner because no single tool is going to be absolute perfection for every single task.
When people are discussing this topic with me, the four tools typically in question are SQL*Plus, SQLcl, SQL Developer Classic (the Java application), and the SQL Developer extension for VS Code.
For me the decision making process is simple, and yes I know it’s a cliche That is “Right tool for the right job“.
Let me give you some examples. If I’m writing a shell script to send to a customer for them to run something in SQL, then I know that no matter what version of the database they have, there will definitely be a SQL*Plus installation on it. Thankfully, in the later releases SQLcl will also be sitting there inside ORACLE_HOME, but the reality is not all customers are running 26ai 19c etc. I wish they were. A lot of customers I deal with are often stuck on 12c, 11g, 10g, 9i etc. So if I’m sending them a program or advising them on a program that I want to make sure will definitely run, then I’ll probably make the assumption that SQL*Plus is going to be the thing to run the script. I’ll probably add a little addenda for them saying “Hey, you should have a look at SQLcl” 
Similarly, even when I’m just running something quick and dirty here at home, I often start with SQL*Plus because its startup time is lightning fast. SQLcl has made enormous strides in that area over its releases, but SQL*Plus still is a little bit quicker. But if I’ve got a SQLcl session already open, then I’m definitely going to opt for that. It’s not about tool preference – it’s just about “What is the easiest way for me to run a SQL statement against my database right now?“. Or perhaps I’m doing some performance timing and for those that don’t know there’s a stopwatch style timer built right into SQL*Plus which even allows nesting of timers. It’s a very cool little tool inside SQL*Plus that I don’t think any of the other tools have. (I made a video on that here https://youtu.be/B0NIs645-OY)
Don’t get the impression that I’m dunking on SQLcl, it is vastly superior to SQL*Plus in almost every other means. The command history is better, the command editing is better, there’s autocomplete as your enter SQL. It’s got a nice SQL formatter as well, but I’ll come back to that in terms of why I often choose different tools. But there’s Liquibase integration, the PROJECT subsystem, plus great hooks into APEX, DataPump and more. Also even just simple things like outputting data in JSON and XML format, etc place it above SQL*Plus. There’s lots of cool stuff in SQLcl.
But that doesn’t mean that I’m not partial to firing up the occasional GUI. Just because I use command line tools doesn’t mean I’m one of those dinosaurs getting on their high horse and claiming that GUIs are for amateurs. As I said, right tool, right job. I still regularly use SQL Developer Classic. It’s got an excellent object browser and plenty of facilities there more focused toward DBAs. Those facilities are slowly being moved over to the SQL Developer VS Code Extension, but in the interim I’m happy to keep using SQL Developer Classic for those particular needs. Similarly, I’ll typically lean toward SQL Developer Classic for formatting SQL – simply due to the fact that I laboured long and hard to customise the formatter to be “just right” for me. It’s not the formatter functionality directly, it’s the time I spent customising it. When I find time to do the same in the other tools, that will no longer be a differentiator.
But of course using SQL Developer Classic comes with a cost. It’s got a larger memory footprint, takes a while to start up and it’s a Java based application and as we know the world has generally moved away from them in terms of desktop GUIs. A typical modern developer is going to be more familiar with VS code than they are with a bespoke Java app.
Hence for anyone that is doing modern development they are probably using VS Code on a daily basis and therefore it makes a lot of sense to use the SQL Developer Extension VS Code in preference to the other tools. It’s got similar code completion facilities and of course coming along for the ride is Git integration, terminal integration, and all the other integrations made possible with the vast array of extensions. But just to sound like a broken record when it comes to “Right tool, Right job” – when I’m traveling I’ll often not use the VS Code extension, not for any functionality grounds. Just more the fact that at my age I’m increasingly getting worse in my eyesight and so I’ll use either SQL*Plus or SQLcl simply to gain access to as much screen real estate as possible in the CLI. VS Code has so many cool panels etc but that actually chews up screen real estate on my small laptop screen. At home the opposite is true I’ve got this huge big monitor and therefore VS Code is the perfect solution there.
Hopefully you’re starting to see a common theme here. For a given task, on a given machine, for a given requirement, I will probably pick one of the four tools that best suits that requirement. It doesn’t mean I hate the other three. It doesn’t mean I’m always going to use a single tool. It means I’m going to pick the tool that’s going to make me the most productive for the given task at hand. I would encourage you to do the same. It’s so easy to get stuck into religious battles about which tool you should be using, which version of the database you should be using, which data modelling approach you should be using. The moment you get stuck into picking one over all others, you’re probably missing out on something.
