Setting Up a New ORDS DB Pool for the API Gateway

Adding a new REST-enabled database pool to Oracle REST Data Services (ORDS) is one of those tasks that's simple once you've done it — but easy to get wrong the first time if you're piecing it together from scattered docs. Here's a clean walkthrough of standing up a dedicated api pool and routing traffic to it through Apache.

1. Create the API DB Pool

From the ORDS bin directory, run the install command in config-only mode, targeting your existing ORDS config folder:

cd /opt/ords/24.1/bin
./ords --config /etc/ords/myapp-prod/ install --config-only --db-pool api --admin-user SYS \
  --db-hostname db-host.example.com --db-port 1521 --db-servicename myapp.example.com \
  --feature-sdw true --feature-rest-enabled-sql true --gateway-mode proxied --gateway-user APP_SELFSERVICE \
  --proxy-user --password-stdin << 'EOF'
your_ords_public_user_password
your_proxy_user_password
EOF

A few things worth calling out about this command:

• --config-only means ORDS just writes the pool configuration — it doesn't touch the schema or attempt a full install, which is what you want when you're adding a pool to an already-running instance.

• --gateway-mode proxied combined with --gateway-user APP_SELFSERVICE and --proxy-user sets this pool up to connect through a proxy user rather than authenticating directly as the schema owner.

• --feature-sdw true and --feature-rest-enabled-sql true turn on Schema Design Workshop and REST-enabled SQL for this pool.

• You'll be prompted for the ORDS_PUBLIC_USER password, or you can pipe it in via --password-stdin as shown above.

Verify the pool

Once it's created, confirm the configuration landed the way you expect:

./ords --config /etc/ords/myapp-prod/ config list --db-pool api

Restart and tail the logs

systemctl restart ords-myapp-app.service
journalctl -f -n 500 -u ords-myapp-app.service

Keep the journalctl tail open while the service comes back up — this is the fastest way to catch a bad hostname, port, or credential before it turns into a support ticket.

2. Modify httpd.conf

With the pool live on the ORDS side, the last step is telling Apache how to route requests to it.

Open httpd.conf and find the existing block that proxies your back-office pool — look for the ProxyPass lines pointing at your ORDS backend port (commonly 8080). Duplicate that block and change only the path prefix so it points at the new api pool:

ProxyPass        /myapp/apps/api  http://<ords-backend-host>:8080/api/
ProxyPassReverse /myapp/apps/api  http://<ords-backend-host>:8080/api/

A couple of guardrails here:

• <ords-backend-host> and the port must match whatever your existing back-office ProxyPass block already uses — don't guess a new host or port, mirror what's already working.

• This new block needs to live inside the same <VirtualHost> section as your existing ORDS proxy rules, not a separate one.

Test and reload

Always validate the config before reloading a production Apache instance:

httpd -t
systemctl reload httpd

httpd -t will catch syntax errors before they take the whole vhost down — never skip straight to reload.

A note on the httpd.conf block

Since every environment's httpd.conf differs, the exact host, port, and surrounding directives in your file may not match the example above one-to-one. If you paste in the current back-office ProxyPass / ProxyPassReverse lines from your own httpd.conf, it's straightforward to mirror them exactly for the new api path rather than guessing at the values.

That's the full loop: provision the pool in ORDS, verify it, restart the service, and then extend the Apache proxy config so external requests actually reach it. Small task, but one where following the existing patterns in your config — rather than improvising new ones — is what keeps it boring (in the good way).