The marketplace and Oracle.com download pages have been updated for version 26.3 of SQL Developer for VS Code. Just last week we reached 1,000,000 installs – thanks everyone for your continued support!

Read the changeLog for a detailed listing of new features and bug fixes.
If you see in the bugs fixed that the extension startup time has been approved, note we’ve cut at least 5 seconds off the startup time, but we’re not finished on this task, you can expect it get much faster over the next update or few.
Here’s a brief look at some of what you can expect in 26.3.
User request: custom data filtering
While browsing tables or views or materialized views, let us put in our own WHERE clause – just like we had in SQL Developer ‘Classic.’

These filters are automatically saved. Recall or delete them via the dropdown control.
User request: copying grids with column headers
Folks like copy and paste and using their clipboards. Getting the data is one thing, but being able to also capture the column headers is super-useful.

- Macs: Alt (option) + Cmd + C
- Windows: Alt + Ctrl + C
User request: AutoTrace
Ok, this isn’t just a simple implementation of our AutoTrace from SQL Developer ‘Classic’ and/or SQLcl. It’s much more than that! Not only do gather session stats, run your query, run sessions stats again, and attach the runtime execution plan, we also provide some very nice visualizations to help you see what’s happening with your ‘slow’ query.

If you’re merely looking for the traditional text output, you’ll find that on the Plan Report page.
User request: Sort PL/SQL packages by name/type
Instead of seeing the tree / code navigator as its declared in the source, you can now also sort the list so it’s easier to find the method you’re looking for.

A lot more comes via SQLcl.
I’ll do a standalone post for SQLcl 26.3 later this week, but if you update your agent settings to point to the new extension location for SQLcl, you’ll find some new MCP Tools. And if you browser the command list you’ll find a couple of new commands.
2 Comments
Hi, a question about how, User request: custom data filtering, works.
does the filter do a full table scan on the database and pull it down to the PC.
or
do a query on the database and just send the filtered information back ?
We run a query. Instead of SELECT * FROM, we run SELECT * FROM WHERE…
The execution plan is determined by your data model, statistics, and what our CBO determines is the ‘best path’ to the results.
So short answer is “do a query on database and just send the filtered results back”