Skip to main content
Databunker Pro stores its encrypted vault in a SQL database. Alongside PostgreSQL (the default) and MySQL, it supports Oracle Database. The Oracle backend is built into the standard image and selected automatically at startup when the ORACLE_HOST environment variable is set — there is no separate build or plugin. The driver is the pure-Go go-ora client.

Choose an edition

Before you provision, pick the edition that matches the features you need. Format-preserving tokenization stores its data in a range-partitioned tokens table, and table partitioning is an Enterprise Edition option — it is not available in SE2 (or in any release, including 23ai, without EE). On SE2, Databunker Pro creates the full user-record schema and runs normally; the partitioned tokens table is not created, so the format-preserving tokenization feature is unavailable.
Rule of thumb: If you only tokenize user records, Standard Edition 2 is enough — and on AWS RDS it is available with a bundled license (no Oracle license to procure). If you need format-preserving tokens (credit cards, deterministic field tokens), use Enterprise Edition.

Connection settings

Point Databunker Pro at Oracle with these environment variables:
Oracle limits passwords to 30 bytes and parses them as identifiers. Use a short, letter-initial, alphanumeric password for the schema user (avoid long hex strings and special characters).
When ORACLE_SSL_MODE enables TLS, Databunker Pro encrypts the connection but does not currently verify the server certificate. The transport is encrypted; server-identity verification is not performed. Keep Databunker Pro and the database on a private network.

Create the schema user

Databunker Pro creates its own tables and indexes on first start, but it needs a schema user to own them. Connect as a privileged user (a DBA, or the RDS master user) and create it once:
Unlike PostgreSQL, Oracle has no separate databunkerdb database — the schema is the namespace, so there is nothing else to create. Then set ORACLE_USER_NAME=bunkeruser and ORACLE_USER_PASS=… and start Databunker Pro.

Docker Compose

Point the Databunker Pro service at your Oracle instance through its environment file:
.env/databunker.env
The rest of the Compose file is identical to the Docker Compose guide — only the database variables change.

AWS RDS for Oracle

RDS is the most common managed-Oracle target. A few RDS-specific details matter.
1

Create the instance

Choose the edition and licensing model:
  • SE2 with a bundled license — no Oracle license to bring:
  • Enterprise Edition uses --engine oracle-ee and requires Bring-Your-Own-License (--license-model bring-your-own-license). RDS does not offer EE with a bundled license.
The DB name you pass (ORCL, ≤ 8 characters) becomes the ORACLE_SERVICE value.
2

Create the schema user

Connect as the RDS master user (not SYS) and run the CREATE USER block above. The master user has the privileges to create bunkeruser and grant it a quota.
3

Enable TLS (recommended)

RDS does not serve Oracle TLS by default — you enable it with an option group that adds the SSL option and opens the TCPS listener on port 2484 (port 1521 stays plaintext).
Then attach the option group to the instance (--option-group-name databunker-oracle-ssl on create or modify-db-instance), and set ORACLE_PORT=2484 and ORACLE_SSL_MODE=require.
Do not leave SQLNET.CIPHER_SUITE at the RDS default. The default (SSL_RSA_WITH_AES_256_CBC_SHA) is a legacy RSA-CBC cipher that Go’s TLS stack does not offer, so the go-ora driver cannot complete the handshake and you will see tls: handshake failure. Pin a modern ECDHE-GCM suite such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, which both RDS and the driver support.

Verify

Once Databunker Pro is running against Oracle, confirm it is serving:
For automated first-time setup, see Unattended installation — the flow is identical; only the ORACLE_* variables replace the PGSQL_* ones.

Next steps