Database guides
Oracle Database
A native OCI connection to Oracle — no JDBC, no middleware. It needs Oracle Instant Client on your machine; here is how to get it.
AddisDB connects to Oracle through the native Oracle Call Interface, the same C API Oracle’s own tools use. There is no Java runtime and no JDBC bridge involved — but OCI does require Oracle’s client library on your machine, which is the one extra step this engine has.
Who it is for
Oracle Database runs a large share of the world’s core financial, ERP and government systems. Its optimizer, partitioning, PL/SQL and operational tooling are deeply mature, and the platforms built on it tend to outlive the teams that built them.
It also has vocabulary of its own that trips up everyone arriving from Postgres or MySQL: a schema is a user, a "database" in the connection sense is a service, empty strings are NULL, and identifiers are folded to upper case unless you quoted them at creation — which is why so many Oracle column names shout.
You are here because the system of record is Oracle — often behind SAP, PeopleSoft, EBS or a decades-old in-house application — and you want to read and query it from something lighter than a full enterprise IDE.
Install Oracle Instant Client
Do this once per machine. Without it, the connection fails immediately with a clear "client library not found" error.
- Download the Instant Client Basic (or Basic Light) package for your platform from Oracle’s website. It is a free download; you may need an Oracle account.
- macOS: unzip it to ~/lib or /usr/local/lib. On Apple Silicon, take the ARM64 build.
- Linux: unzip it and either add the directory to LD_LIBRARY_PATH or register it with ldconfig.
- Windows: unzip it and add the folder to your PATH.
- Restart AddisDB so it picks up the new library path.
An architecture mismatch is the failure people lose the most time to: an x86_64 Instant Client will not load into an ARM build of the app, and the error says only that the library could not be found.
Set up the database side
- Get the host, port (1521 by default) and the service name — not the SID — from your DBA or the tnsnames.ora entry.
- Oracle Autonomous Database: download the wallet from the OCI console; your connection details come from tnsnames.ora inside it.
- Ask for a read-only account rather than reusing the application schema owner.
- Ask for SELECT_CATALOG_ROLE at the same time if you want the Live Monitor populated — it is what the v$ views require.
- Local: the gvenzl/oracle-free Docker image gives you a working XEPDB1 service to test against.
# A local Oracle Free instance with the XEPDB1 service
docker run -d --name oracle -p 1521:1521 \
-e ORACLE_PASSWORD=secret gvenzl/oracle-free
Connect from AddisDB
- New Connection → Oracle. Port prefills to 1521 and the username to system.
- Put the service name in the Database field — for example XEPDB1 or ORCLPDB1. AddisDB assembles the Easy Connect descriptor //host:port/service for you.
- If you have a full TNS descriptor or an alias instead, paste it into the Connection URL box.
- Test, then Save.
ORA-12514 means the listener answered but has no service registered under that name — the value in Database is a SID or a typo. ORA-12541 means nothing is listening on that host and port at all.
Querying without a LIMIT clause
Oracle has no LIMIT. AddisDB caps previews as rows are decoded rather than rewriting your SQL, so what you sent is what ran. When you want the cap in the statement itself, FETCH FIRST n ROWS ONLY is the modern form, and ROWNUM the one you will find in older code.
SELECT order_id, customer_id, total
FROM orders
WHERE created_at > SYSDATE - 7
ORDER BY created_at DESC
FETCH FIRST 50 ROWS ONLY;
What AddisDB gives you
- Schema introspection across users and schemas, with the foreign-key diagram and ⌘K search.
- Automatic row capping — Oracle has no LIMIT clause, so AddisDB caps previews on decode instead of rewriting your SQL.
- The full safety model — read-only connections, prod tagging, and destructive-statement detection before anything runs.
- Mock data with real bound parameters, so dates and identity keys land correctly rather than depending on session formatting.
- AI querying grounded in your real schema, and one-click repair for failing SQL.
- The Chart view, notebooks, and query tabs with history.