Dory now supports Oracle Database.
If your team keeps core business data, finance data, ERP data, order systems, reporting systems, or long-running enterprise applications in Oracle, you can now connect Oracle to Dory and work with it in the same modern data workspace. This release is not just about adding another connection type. Oracle now works across Dory's core data workflow: creating connections, resolving Oracle services, browsing schemas, inspecting tables and views, exploring functions and procedures, previewing data, running Oracle SQL, and using AI assistance with Oracle-aware context.
Oracle is still a critical database for many enterprise systems. It often holds production data that has run reliably for years, and it is frequently tied to finance, supply chain, customer management, internal operations, audit reporting, and other high-value workflows.
But working with Oracle is not always lightweight. Analysts need to understand service names, schemas, identifier casing, and system catalog views. Engineers need to inspect tables, views, indexes, primary keys, sequences, and stored procedures. When queries fail, Oracle's SQL dialect differences also matter.
With Oracle support, Dory brings that context into a unified workspace. You do not need to jump between tools just to find the right object, and you do not need to treat Oracle as a generic SQL source and guess the syntax.
You can create an Oracle connection from Dory's Connections page.
Dory supports the connection details Oracle users expect:
1521
as the default portORCLPDB1
oracle://db.example.com:1521/ORCLPDB1
After the connection is saved, Oracle appears alongside your other data sources. Dory recognizes it as a dedicated database type instead of treating it like Postgres, MySQL, or SQL Server.
Once connected, Oracle becomes available in Dory Explorer and the SQL Console sidebar.
You can browse:
Dory filters common Oracle system schemas so the workspace stays focused on user-maintained business objects. For a database with many object layers and long-lived historical objects, this matters: opening a connection should show the data you can work with, not bury it under system objects.
The SQL Console sidebar also prefers the schema that matches the current connection identity, helping you get into the right query context faster.
For Oracle tables and views, Dory can show useful object-level details: This gives you the context you need before writing SQL. You can confirm column types, primary keys, indexes, and table scale before deciding how to query, instead of running a large query just to learn the structure.
For data previews, Dory uses Oracle's FETCH FIRST n ROWS ONLY
and OFFSET ... FETCH NEXT ...
syntax instead of another database's LIMIT
.
Many Oracle databases keep important business logic in functions and stored procedures. Dory now treats these objects as explorable database resources.
When you open a function or procedure, you can see:
For procedures, Dory generates a BEGIN ... END;
style sample call. For functions, Dory generates a sample call from dual
. These details make it easier to understand existing database logic and reduce trial and error when calling it.
SQL Console now handles Oracle as its own SQL dialect.
That means Dory can more naturally handle Oracle syntax, including:
FETCH FIRST n ROWS ONLY
or ROWNUM
to limit rowsLIMIT
on Oracle queriesdual
when Oracle requires a one-row sourceOracle and other relational databases all use SQL, but small dialect differences are enough to break a query. Dory now treats Oracle as Oracle instead of pushing it through an oversimplified generic SQL template.
Dory's AI assistance now understands Oracle query conventions.
When you ask Dory to generate SQL, fix SQL, or explain a query, it can apply Oracle-specific rules:
FETCH FIRST n ROWS ONLY
or ROWNUM
to limit result sizeALL_*
and USER_*
catalog views when metadata is neededdual
only when Oracle requires a one-row sourceThis matters in real workflows. AI should not generate LIMIT
for Oracle users, and it should not use PostgreSQL pg_catalog
or SQL Server sys
catalog views to inspect Oracle metadata.
Oracle support makes Dory a better fit for real multi-database environments.
Many teams do not use just one database. Production systems may run on Oracle, analytics services may use Postgres or ClickHouse, internal tools may use MySQL or SQL Server, and local analysis may depend on DuckDB, SQLite, or file-based data.
For analysts, this means finding Oracle business data and starting analysis faster.
For engineers, this means seeing schemas, tables, views, indexes, functions, and procedures more clearly.
For data and operations teams, this means Oracle can live in the same workspace as every other data source.
Dory's goal is not to flatten every database into the same experience. It is to respect each database's behavior inside a unified workspace.
You can try it with these steps:
From there, you can browse schemas, inspect tables and views, preview data, explore functions and procedures, and ask Dory to help write or fix Oracle SQL. Oracle support is an important step toward supporting real enterprise data environments in Dory.
We will keep improving schema exploration, query assistance, database object understanding, and cross-source workflows so teams can work more smoothly across complex data systems.
If Oracle is part of your data stack, Dory can now work with it.