Oracle Backend for Firebase (Fusabase) on a Self-Hosted Dockerized Oracle Database + ORDS Stack

A step-by-step field report: enabling Oracle’s new Firebase-compatible BaaS toolkit on an existing Oracle AI Database 23ai + ORDS 26.1 setup running in separate Docker containers, including every command, every wrong turn, every error message, and a working Flutter app built on top of it at the end.

Environment: Ubuntu 24.04 LTS · Oracle AI Database 26ai (23.26.1.0.0) in Docker · ORDS 26.1.2 in a separate Docker container · Docker network shared between both containers

What is Oracle Backend for Firebase?

Oracle Backend for Firebase, internally referred to as Fusabase, is a free toolkit shipped as part of Oracle REST Data Services (ORDS) 26.1+. It gives mobile and web developers Firebase-style building blocks (Authentication, document-style database access, file storage, security rules, vector search, and an attestation-based App Trust layer) backed directly by an Oracle AI Database, with open-source client SDKs for iOS, Android, Flutter, and JavaScript/Web.

The key architectural point: if you already have ORDS deployed, you don’t need a separate managed plane or data plane. Fusabase runs directly on top of your existing Oracle Database + ORDS installation.

Environment & Prerequisites

docker-compose reference

Both containers already existed and were running well before this exercise. The goal was to add the Fusabase feature without breaking the existing APEX/ORDS setup.

Database container

version: '3.9'
services:
  database:
    image: oracle/database:23.26.1-ee
    container_name: database23
    hostname: database
    restart: always
    ports:
      - "1522:1521"
    environment:
      ORACLE_PWD: "<SYS_PASSWORD>"
      ORACLE_CHARACTERSET: "AL32UTF8"
      ORACLE_SID: "ORCL"
      ORACLE_PDB: "ORCLPDB"
    volumes:
      - oracle-23c-data:/opt/oracle/oradata
    networks:
      - database-ords
networks:
  database-ords:
    name: database-ords
volumes:
  oracle-23c-data:
    name: oracle-23c-data

ORDS container

version: '3.9'
services:
  ords:
    image: ords-26.1:latest
    container_name: ords26
    restart: always
    ports:
      - "8282:8080"
    environment:
      DBHOST: database
      DBPORT: 1521
      DBSERVICENAME: ORCLPDB
      ORACLE_PWD: <SYS_PASSWORD>
    volumes:
      - ords-config:/etc/ords/config
      - /home/apex26/images:/opt/oracle/apex/images
    networks:
      - database-ords
networks:
  database-ords:
    external: true
    name: database-ords
volumes:
  ords-config:
    name: ords-config

1Check Database Compatibility

Connect as SYS in the CDB root and check the current COMPATIBLE setting and version:

docker exec -it database23 bash
sqlplus / as sysdba

show parameter compatible;
SELECT banner_full FROM v$version;

NAME              TYPE    VALUE
----------------- ------- ------
compatible        string  23.6.0
noncdb_compatible boolean FALSE

"Oracle AI Database 26ai Enterprise Edition Release 23.26.1.0.0 - Production
Version 23.26.1.0.0"

COMPATIBLE = 23.6.0 is below the required 23.9.0. This needs to be raised before continuing.

Also confirm which container you’re currently in. This matters because COMPATIBLE can only be changed from CDB$ROOT:

SELECT SYS_CONTEXT('USERENV','CON_NAME') FROM DUAL;

If this returns your PDB name (e.g. ORCLPDB) instead of CDB$ROOT, switch containers first:

ALTER SESSION SET CONTAINER = CDB$ROOT;

2Raise COMPATIBLE to 23.9.0

From CDB$ROOT:

ALTER SYSTEM SET COMPATIBLE='23.9.0' SCOPE=SPFILE;

This setting only takes effect after a real instance restart. Since the database runs on a Docker named volume and not container-local storage, a SHUTDOWN/STARTUP from within the container is completely safe. The container itself keeps running, only the Oracle instance process cycles.

docker exec -it database23 sqlplus / as sysdba

SHUTDOWN IMMEDIATE;
STARTUP;

Database closed.
Database dismounted.
ORACLE instance shut down.
ORACLE instance started.

Total System Global Area 1.8945E+10 bytes
Fixed Size                 11500648 bytes
Variable Size            4026531840 bytes
Database Buffers         1.4898E+10 bytes
Redo Buffers                8855552 bytes
Database mounted.
Database opened.

NAME       TYPE    VALUE
---------- ------- --------
compatible string  23.9.0

3Enable Extended String Support (32k Types)

Check the current setting inside the PDB:

ALTER SESSION SET CONTAINER=ORCLPDB;
SELECT value FROM v$parameter WHERE name = 'max_string_size';

Result: STANDARD, needs to become EXTENDED.

All ALTER PLUGGABLE DATABASE commands must run from CDB$ROOT, so switch back first:

ALTER SESSION SET CONTAINER=CDB$ROOT;
ALTER PLUGGABLE DATABASE ORCLPDB CLOSE;

docker exec -it database23 sqlplus / as sysdba
SELECT name, open_mode FROM v$pdbs;

Once the PDB is confirmed closed, open it in UPGRADE mode and run the Oracle-provided script:

ALTER PLUGGABLE DATABASE ORCLPDB OPEN UPGRADE;
ALTER SESSION SET CONTAINER=ORCLPDB;
ALTER SYSTEM SET max_string_size = extended;
@?/rdbms/admin/utl32k.sql

The script prints several DOC> warning blocks. These describe what error would appear if a prerequisite were missing, they are not errors themselves. Look for the actual outcome lines: PL/SQL procedure successfully completed, 508 rows updated, Commit complete, No errors.

Then return the PDB to normal service and verify:

ALTER SESSION SET CONTAINER=CDB$ROOT;
ALTER PLUGGABLE DATABASE ORCLPDB CLOSE;
ALTER PLUGGABLE DATABASE ORCLPDB OPEN;

ALTER SESSION SET CONTAINER=ORCLPDB;
SELECT value FROM v$parameter WHERE name = 'max_string_size';

4Configure the TDE Wallet

Check whether a working wallet already exists:

ALTER SESSION SET CONTAINER=CDB$ROOT;
SELECT WRL_TYPE, WRL_PARAMETER, STATUS FROM V$ENCRYPTION_WALLET;

WRL_TYPE       FILE
WRL_PARAMETER  /opt/oracle/admin/ORCL/wallet
STATUS         NOT_AVAILABLE

A path is configured but nothing usable exists there yet. Confirmed on disk: the target directory doesn’t even exist (only an unrelated xdb_wallet folder was present, plus an unrelated application-level wallet folder at /opt/oracle/oradata/wallet used by other integrations. Do not confuse the two, they are unrelated to TDE).

Create the wallet directory with correct ownership and permissions (inside the container, plain shell):

mkdir -p /opt/oracle/admin/ORCL/wallet
chown -R oracle:oinstall /opt/oracle/admin/ORCL/wallet
chmod 700 /opt/oracle/admin/ORCL/wallet

Back in sqlplus, set wallet_root and restart the instance for it to take effect:

ALTER SYSTEM SET wallet_root='/opt/oracle/admin/ORCL/wallet' SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;
show parameter wallet_root;

Then configure and open the keystore:

ALTER SYSTEM SET tde_configuration='KEYSTORE_CONFIGURATION=FILE' SCOPE=BOTH;

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE
  IDENTIFIED BY "<strong_keystore_password>";

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
  IDENTIFIED BY "<strong_keystore_password>" CONTAINER=ALL;

ADMINISTER KEY MANAGEMENT SET KEY
  IDENTIFIED BY "<strong_keystore_password>" WITH BACKUP CONTAINER=ALL;

SELECT WRL_TYPE, WRL_PARAMETER, STATUS FROM V$ENCRYPTION_WALLET;

WRL_TYPE      FILE
WRL_PARAMETER /opt/oracle/admin/ORCL/wallet/tde/
STATUS        OPEN

5Create the Project-Owning Schema

Every Fusabase project is owned by exactly one schema. Create a dedicated tablespace and user inside the PDB:

ALTER SESSION SET CONTAINER=ORCLPDB;

CREATE TABLESPACE fusabase_tbs
  DATAFILE 'fusabase_tbs01.dbf' SIZE 50M AUTOEXTEND ON
  EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

CREATE USER fusabase_user IDENTIFIED BY "<password>"
  DEFAULT TABLESPACE fusabase_tbs
  QUOTA UNLIMITED ON fusabase_tbs;

GRANT CREATE SESSION TO fusabase_user;
GRANT RESOURCE TO fusabase_user;
GRANT DBFS_ROLE TO fusabase_user;

Verify:

SELECT username, default_tablespace, account_status
FROM dba_users WHERE username = 'FUSABASE_USER';

SELECT tablespace_name, status
FROM dba_tablespaces WHERE tablespace_name = 'FUSABASE_TBS';

SELECT granted_role FROM dba_role_privs WHERE grantee = 'FUSABASE_USER';

6Create a Dedicated DBA Admin User

The schema-enablement procedure (OBAAS_ADMIN.OBAAS_ENABLE_SCHEMA) must not be run as SYS. Oracle’s own documentation flags an ORA-06598 error in that case. Create a separate account with the DBA role instead:

CREATE USER fb_admin IDENTIFIED BY "<password>";
GRANT DBA TO fb_admin;
GRANT CREATE SESSION TO fb_admin;

Log in as this new user, over the network this time, to confirm listener and service connectivity, not just a local bequeath connection:

sqlplus fb_admin@localhost:1521/ORCLPDB

7Enable the Feature in ORDS

Move to the ORDS container, a separate container from the database, connected via the shared database-ords Docker network:

docker exec -it ords26 bash
ords --version

Before running anything, verify where the ORDS config actually lives. This determines whether the install survives a container recreate:

docker inspect ords26 --format '{{ range .Mounts }}{{ .Source }} -> {{ .Destination }}{{ println }}{{ end }}'

/home/apex26/images -> /opt/oracle/apex/images
/var/lib/docker/volumes/ords-config/_data -> /etc/ords/config

Run the interactive installer:

ords --config /etc/ords/config fusabase install

Walk through the interactive prompts:

1. Select the database pool. ORDS auto-detects the existing pool from its own saved configuration:

   [1] default    jdbc:oracle:thin:@//database:1521/ORCLPDB
   Choose [1]: 1

   This is the same connection ORDS has already been using in production for the existing APEX app, confirmed independently with:

   docker exec ords26 env | grep DB
   # DBHOST=database
   # DBPORT=1521
   # DBSERVICENAME=ORCLPDB

2. Feature configuration. Accept the defaults:

   [1] Enable Feature FUSABASE: Yes
   [2] Encryption passphrase for FUSABASE: <generate>
   Choose [A]: A

3. Administrator credentials:

   Enter the administrator username: sys as sysdba
   Enter the database password for sys as sysdba: <type manually>

2026-08-05T14:21:18.184Z SEVERE   Failed to connect to user: sys as sysdba
jdbc:oracle:thin:@//database:1521/ORCLPDB
ORA-01017: invalid credential or not authorized; logon denied

Retrieving information.
The setting named: feature.fusabase was set to: true in configuration: default
The setting named: fusabase.secret.encKey was set to: ****** in configuration: default
Installing Oracle Backend for Firebase version 26.1.1-260430 in ORCLPDB
Completed installation for Oracle Backend for Firebase version 26.1.1-260430. Elapsed time: 00:00:05.801

8Enable the Schema for Fusabase

Now that the installer has created the OBAAS_ADMIN package, log in as the dedicated DBA user, not SYS, and run the enablement procedure:

docker exec -it database23 bash
sqlplus fb_admin@localhost:1521/ORCLPDB

BEGIN
  OBAAS_ADMIN.OBAAS_ENABLE_SCHEMA(
    'FUSABASE_USER',
    'BASE_PATH',
    'fusabase_user',
    FALSE
  );
END;
/
COMMIT;

Confirm the schema received the BAAS_ROLE:

SELECT granted_role FROM dba_role_privs WHERE grantee = 'FUSABASE_USER';

GRANTED_ROLE
------------
RESOURCE
DBFS_ROLE
BAAS_ROLE

9Restart ORDS So the Console Tile Appears

Opening the ORDS landing page immediately after installation did not show an “Oracle Backend for Firebase” tile yet. ORDS loads its available Console tiles at process start, before the feature was enabled.

http://<host>:8282/ords/_/landing

Fix: restart the ORDS container. Safe, the configuration lives on the named volume, nothing is lost:

docker restart ords26
docker logs -f ords26   # watch until it's up, then Ctrl+C

Reload the landing page. The “Oracle Backend for Firebase” tile now appears.

10Sign In to the Console (and Fix “Invalid Credentials”)

Open the Console sign-in page. This may sit behind a reverse proxy or custom domain rather than the raw host:port. That’s fine, it’s the same ORDS instance:

https://<your-domain-or-host>/ords/baas-console

The sign-in form asks for three things:

• Path (Advanced) — the ORDS schema mapping path/alias. Use fusabase_user.
• Username — fusabase_user
• Password — the schema’s database password

Invalid credentials
If your ORDS schema alias is different from your username, you
can set it using the "Path" input in the "Advanced" options

docker exec -it database23 sqlplus / as sysdba

ALTER SESSION SET CONTAINER=ORCLPDB;
ALTER USER fusabase_user IDENTIFIED BY "<new_password>";

11Create Your First Project in the Console

With the sign-in issue resolved, the Console loads to an empty “Your projects” screen. This is the actual Oracle Backend for Firebase UI, running on top of the exact stack configured in Steps 1 through 10.

Click Create project. Name it, then choose between manual setup and quickstart. Quickstart sets up Authentication and Storage for you automatically, both can be reconfigured later:

The project appears on the dashboard tagged IN DEV, with 0 applications registered so far. This status maps directly to the schema you enabled with OBAAS_ENABLE_SCHEMA in Step 8:

12Register a Flutter App and Install the SDK

Click into the project. The Overview page prompts you to add an application, with buttons for Web, Android, iOS, and Flutter. For this walkthrough, the target was a Flutter app talking to Oracle instead of Firebase:

Clicking Flutter opens a three-step wizard: Register application, Install SDK, Configure SDK. Step 1 just asks for an app nickname:

Step 2 offers two ways to install the SDK. The ZIP option downloads the SDK and references it by local path in pubspec.yaml:

The GitHub option is simpler if you don’t want to vendor the SDK locally. It just adds a Git dependency:

dependencies:
  fusabase:
    git:
      url: https://github.com/oracle/fusabase-flutter-sdk.git
      ref: {version}

13Configure the SDK with Real Dart Code

Step 3 generates ready-to-paste Dart code, already filled in with your actual project ID, app ID, storage bucket, and ORDS host. This is the part that saves the most time. Nothing here is a placeholder, it comes straight from the project you just created:

import 'package:fusabase/oracledb.dart';
import 'package:fusabase/core.dart';
import 'package:fusabase/auth.dart';
import 'package:fusabase/storage.dart';

Map<String, dynamic> options = {
    "schema": "fusabase_user",
    "app_name": "demoapp",
    "app_type": "DART",
    "app_id": "<your_app_id>",
    "objs_type": "dbfs",
    "project_id": "<your_project_id>",
    "storage_bucket": "<your_storage_bucket>",
    "auth_type": "base",
    "auth_id": "<your_auth_id>",
    "ords_host": "https://<your-ords-host>/ords/fusabase_user/"
};

FusabaseOptions fusabaseConfig = FusabaseOptions(options);

// initialize app
FusabaseApp fusabaseApp = Fusabase.initializeApp(options:fusabaseConfig);
// get database instance
final fusabaseDB = FusabaseOracledb.instance;
// get object store instance
final fusabaseStorage = FusabaseStorage.instance;
// get auth instance
final fusabaseAuth = FusabaseAuth.instance;

For Android specifically, the wizard also generates a manifest snippet for the OAuth callback activity. This has to go into AndroidManifest.xml or sign-in redirects silently fail:

<activity
    android:name="com.oracle.mobile.fusabase.flutter.FusabaseCallbackActivity"
    android:exported="true">
    <intent-filter android:label="fusabase_dart">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="baasmobile<app id in lowercase>" />
    </intent-filter>
</activity>

14Understand Collections, Documents, and Security Rules

Before writing any app code, it’s worth opening the Database tab. Oracle Backend for Firebase does not use tables and rows. It stores data in documents organized into collections, the same mental model as Firestore:

By default, all data is private. The Security rules tab is where you decide who can read, write, update, or delete. The default rule blocks everything until you explicitly allow it:

match /{document=**} { allow read, write: if false; }

The sandbox panel on the right lets you simulate a request (Get, List, Create, and so on) against a specific document path, with or without authentication, before you commit to a rule change. That is worth using before opening anything up in a real project.

15Build and Run a Working Flutter Notes App

With the SDK wired in, the default Flutter counter demo runs first, just to confirm the toolchain and the Fusabase initialization code both work before writing real features:

From there, the actual feature work (a simple notes app backed by FusabaseOracledb and FusabaseAuth) went faster with an AI coding agent reading the SDK’s own source directly, rather than guessing at an API surface designed to resemble Firebase’s:

The result: a notes screen that writes to a notes collection through fusabaseDB, with each document carrying the note text, a timestamp, and the creating user. Running on a real device:

And the proof that it’s actually Oracle underneath, not a local mock: the same note appears as a live document in the Fusabase Console’s Database tab, under the notes collection, with text, created_at, and created_by fields exactly as written by the app:

That closes the loop: a self-hosted Oracle Database and ORDS stack, enabled for Fusabase through nothing but SQL*Plus and the ORDS CLI, now backing a real Flutter app with a Firebase-shaped SDK and zero third-party BaaS involved.

Full List of Errors Encountered (and Fixes)

Final Credentials / Connection Summary

# ORDS landing page (shows the Console tile)
http://<your-host>:8282/ords/_/landing

# Fusabase Console direct sign-in (can sit behind a reverse proxy / custom domain)
https://<your-domain-or-host>/ords/baas-console
  Path:     fusabase_user
  Username: fusabase_user
  Password: <current schema password>

# Fusabase SDK connection (example for Flutter)
ords_host: http://<your-host>:8282/ords/fusabase_user/
schema: fusabase_user