{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

I spend my days on the infrastructure side of things — migrations, capacity planning, licensing conversations, moving workloads onto Oracle Autonomous AI Database and OCI.

I don't write mobile apps. I've never shipped an Android build or wrestled with an Xcode provisioning profile.

So when I first heard about Oracle Backend with Firebase APIs, my honest first reaction was: "that's a developer thing, not my thing , but I relaized a DBA needs to understand ORDS

A few days in, I've had to look into it as my Dev Team asked for some support on this Once our data is on Oracle AI Database, what else can we do with it?" Usually that means analytics, or AI workloads, or vector search for RAG. It almost never means "can our mobile app team build directly on top of this too" — because historically, the honest answer was no. Mobile and web teams reach for Firebase, Supabase, or some other backend-as-a-service, and the database team's carefully governed, audited, encrypted Oracle estate sits in a completely separate world from the app.

What the toolkit actually is, in plain terms

Oracle Backend with Firebase APIs is a free feature of Oracle REST Data Services (ORDS) that lets app developers build mobile and web apps directly against Oracle AI Database, using SDKs for iOS, Android, Flutter, and JavaScript that are deliberately shaped to feel like the Firebase SDKs they already know. Authentication, document-style data storage, file storage, declarative security rules, and AI vector search are all exposed through those SDKs — and all of it runs inside the same database instance, not a separate service bolted on the side.

That last part is the piece that clicked for me. It's not "Oracle built a Firebase clone." It's "Oracle exposed the database you already trust through an interface that app developers already like."

Where exactly the firebase app connects to the database

The app itself never opens a database connection — that's the key thing to understand. There's a hop in between:

App (phone/browser) → HTTPS request → ORDS → SQL/PL-SQL call inside the database → Oracle AI Database (ATP)

Broken down:

1. The SDK talks HTTP, not SQL.
When your app calls something like addDoc() or signInWithEmailAndPassword(), the SDK turns that into a plain HTTPS REST call to the ords_host URL from your app config — the same URL you set in initializeApp().

2. ORDS is the actual thing holding a database connection. ORDS maintains its own JDBC connection pool to the database (that's what got configured during the fusabase install step — host, port, PDB service name). The app, the phone, the browser — none of them ever see a database hostname, port, or credential. They only ever see the ORDS URL.

3. Inside the database, Fusabase ships as server-side PL/SQL packages. ORDS routes each REST call to Fusabase's own API packages running inside the database schema you enabled (the one with BAAS_ROLE). Those packages are what actually read/write the JSON collections, check security rules, and run vector similarity queries — as regular SQL/PL-SQL, on regular tables, in your schema.

4. On ATP specifically, this means the real connection point is whatever ORDS instance is fronting your Autonomous Database — either Oracle's default managed ORDS, or (per what we found last time) a Customer Managed ORDS if you need the install-level access Fusabase requires. Either way, the physical DB connection lives entirely on the ORDS side, using ORDS's own database user/wallet — the app's auth token only proves who the app user is, not a database login.

So the honest one-line answer: the app connects to ORDS over HTTPS; ORDS is what's connected to the database. The app never gets network-level access to ATP itself.

So What ORDS does - A DBA knowhow primer

What ORDS does — the core job list:

  • Turns database objects into REST APIs. Auto-REST enables tables/views with zero code; custom PL/SQL endpoints are hand-mapped to URLs.
  • Holds the actual database connection. Maintains a JDBC connection pool per configured database — clients never connect directly; ORDS hands out pooled sessions to fulfill requests.
  • Handles authentication and authorization at the API layer. OAuth2 (client credentials, roles like SQL Developer), API-key or Basic auth for auto-REST, independent of how the database itself authenticates ORDS's own pool user.
  • Enforces access control on endpoints. Privileges, roles, and rate limiting can be applied per REST module — separate from (but layered on top of) database grants and VPD.
  • Serializes results to standard web formats. JSON by default, plus CSV, GeoJSON, and binary media for BLOBs/files.
  • Provides request-shaping features. Filtering, sorting, pagination, and dynamic bind parameters on auto-REST endpoints without writing SQL for each variant.
  • Generates OpenAPI documentation for whatever it exposes, so consumers get a spec, not just an endpoint.
  • Runs application platforms on top of the database. APEX, SQL Developer Web / Database Actions, and — as of 26.1 — Oracle Backend for Firebase are all delivered through ORDS rather than as separate services.
  • Exposes vector search natively. The /vectorSearch endpoint runs similarity queries against VECTOR columns on auto-REST enabled tables.
  • Acts as a REST bridge for non-relational access patterns — the Database API for MongoDB and Fusabase both route MongoDB- or Firebase-shaped calls into ordinary SQL/PLSQL underneath.
  • Serves AI-facing tooling. MCP Tools for letting AI systems discover database connections, pull schema metadata, and execute SQL/PLSQL.
  • Runs as a separate mid-tier process with its own lifecycle — install, patch, scale, and version independently of the database (standalone Jetty, or deployable to Tomcat/WebLogic); on Autonomous Database, Oracle runs and manages a default instance of it for you, with limited configurability unless you go Customer Managed.

Why that matters from where I sit

A few things stood out to me as someone who thinks about this from the operations and governance side, not the app-building side:

  • One database set of controls. Because the toolkit runs on ORDS on top of Oracle AI Database, everything the DBA team already relies on — auditing, transparent data encryption, partitioning, Data Guard, row-level security — still applies underneath whatever the app developers build. The app team gets a familiar developer experience; the platform team doesn't lose the guardrails they spent years putting in place.

  • Vector search without a second system to babysit. App-driven AI features — semantic search, recommendations, retrieval-augmented generation — can query vectors stored right alongside the relational data, in the same query, under the same rules. For anyone who has had to stand up and secure a standalone vector database just to support one feature, that's a meaningfully smaller footprint to operate and explain to an audit team.

  • It runs wherever ORDS already runs. OCI, AWS, Azure, Google Cloud, on-premises, Cloud@Customer — this isn't a new managed service you have to onboard. If ORDS is already part of your environment, this is a feature you turn on, not a platform you migrate to.

  • App Trust closes a gap I hadn't thought about. Client configuration for these toolkits is public by design — anyone who inspects a deployed app can see it. App Trust adds an attestation layer so the backend can tell a real instance of your app from a script or a copycat using the same config. That's a nice bit of reassurance for anyone worried about what "expose your database to a mobile SDK" might mean for abuse or scraping.

The bigger shift

What I find genuinely interesting isn't the SDK syntax — I'll leave that to the developers. It's what this represents: Oracle AI Database showing up natively in front-end and mobile development conversations, not just backend and analytics ones. For consulting work centered on getting customers onto Oracle AI Database and OCI, that's a new thread worth pulling. A customer's mobile team building a new app is now a legitimate reason to talk about the same database platform their data team already runs on — instead of two separate conversations that never meet.

I still won't be writing the Swift or Flutter code myself. But I'll be paying attention to who is, and I'd encourage anyone in a similar seat — infrastructure, migrations, database platform work — to take a look, even if "developer toolkit" doesn't sound like it's aimed at you. It wasn't aimed at me either, and it still got me interested.

Where to go next

If this piqued your curiosity too:

Oracle Backend with Firebase APIs is generally available today as part of ORDS 26.1.1, and it's free.

How Nabhaas helps you

If you’ve made it this far, you already sense there’s a better way — in fact, you have a way ahead.

If you’d like Nabhaas to assist in your journey, remember — TAB is just one piece. Our Managed Delivery Service ensures your Oracle operations run smoothly between patch cycles, maintaining predictability and control across your environments.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here