Today we’re introducing Oracle Backend for Firebase (Fusabase), a Backend-as-a-Service-style toolkit that lets developers build modern mobile and web applications directly on Oracle AI Database. With this release, Oracle AI Database reaches mobile and web app developers natively, on the same database, in the same deployment posture, and within the same security and compliance boundaries your team already operates. 

The toolkit ships with first-party SDKs for iOS, Android, JavaScript, and Flutter, a unified Console, a CLI, and a feature set covering authentication, database, file storage, declarative security rules, AI vector search, and an attestation-based App Trust layer. Everything runs on top of Oracle AI Database and Oracle Rest Data Services (ORDS). Wherever you run ORDS today, Oracle Backend for Firebase runs there too. There is no separate service to provision, no managed control plane outside your environment, and no data plane outside the database. 

Here is the JavaScript SDK creating and updating a document, the same shape Firebase developers will recognize: 

import { doc, setDoc } from "fusabase/oracledb"; 
 
// Create or update a user document 
await setDoc(doc(db, "users", "Scott"), { 
   displayName: "Scott", 
   photoURL: user.photoURL || null, 
}); 
 
// Create a recipe in a subcollection 
await setDoc(doc(db, "users", "Scott", "recipes", "Cookies"), { 
   title: "Chocolate Chip Cookies", 
   ingredients: ["2 cups flour", "1 cup sugar", "1/2 cup chocolate chips"], 
   steps: ["Mix ingredients", "Bake for 15 min"], 
   category: "Dessert", 
   tags: ["sweet", "baking"], 
}); 

What’s Inside Oracle Backend for Firebase 

Vector Search Next to Your Business Data 

Oracle AI Database 26ai includes native vector storage and similarity search in the engine, and Oracle Backend for Firebase exposes both directly through the SDK. Store dense or sparse vectors alongside your business data and run similarity queries over collections — with cosine, euclidean, or dot-product metrics, optional topK and threshold filters, and a clean findNearest API that mirrors the rest of the SDK shape. Because vectors live in the same Oracle AI Database as the rest of your data, joins between vector results and relational tables happen in one query, governed by the same security rules. There is no separate vector database to provision, secure, or keep in sync. 

This unlocks AI-native experiences alongside the rest of your app: 

  • Semantic search over user-generated content — photos, support tickets, product catalogs, knowledge bases. 
  • Recommendations powered by similarity over the unstructured objects your users already produce. 
  • Retrieval-augmented generation (RAG) for chat and assistant features, grounded in your authoritative data. 

Authentication 

Authentication supports email/password, social sign-in (Google, Facebook, GitHub), SAML SSO, generic OIDC, LDAP, and Oracle Identity and Access Domain. User and session state live in the same Oracle AI Database your application data lives in, so security rules can reference identity directly without a separate user store. The SDK exposes onAuthStateChanged, sign-in / sign-out, and token APIs, and attaches identity tokens to every subsequent SDK call automatically. 

File Storage 

File Storage handles uploads, downloads, listing, and deletion through the SDK’s storage references. Files can be backed by DBFS or OCI Object Storage depending on how your environment is configured. Storage paths are governed by the same declarative security rules that govern your collections, so record-level and file-level access share one rules model and one place to edit them. 

Declarative Security Rules, Enforced in the Database 

Access control is expressed as declarative security rules tied to your collections, documents, and storage paths — and evaluated inside Oracle AI Database next to the data they protect. There is no separate rule engine to operate.  

And because collections are natively inside the Oracle database, the rest of the database keeps working. A VPD policy on a collection table fires on every Fusabase read and write, alongside the rules your app developers wrote. The same goes for auditing, TDE, partitioning, and Data Guard. App-developer rules and DBA-managed controls are two layers on the same data — your DBA team’s existing controls aren’t replaced when using this. 

App Trust — Proof the Request Came From Your App 

Backend security rules can confirm who is making a request — but not, on their own, that the request actually came from your app rather than from a script using the same client config. App Trust is an optional layer that closes that gap. 

App Trust attaches a per-request attestation token that proves the request came from a legitimate instance of your app. At launch, App Trust ships for web apps with a choice of attestation provider — reCAPTCHA v3, reCAPTCHA Enterprise, hCaptcha, and Cloudflare Turnstile. A single initialize AppTrust call at startup wires every subsequent SDK call automatically. The developer does not write per-request code. 

The Fusabase client config  (project ID, app ID, and ORDS host) is public by design, bundled into your client and visible to anyone who inspects the deployed app. Authentication and security rules govern who can do what; App Trust is an additional, optional layer that further restricts requests to your real app instances, regardless of who has the config. Once enabled, the backend rejects any request that does not carry a valid attestation token, so even with a full copy of your client config, an attacker cannot call your backend from a script or a copycat app: 

  • Application-layer DDoS. Script-driven floods are filtered at the edge before they reach the database. 
  • Copycat apps and config extraction. The client config can always be extracted from a deployed app, but a cloned site fails the attestation check and gets nothing. 
  • Compute and quota abuse. Heavy queries, large reads, and vector searches only consume database compute for verified clients, so a bot running off a copied config cannot drive your costs through the roof. 
  • Data scraping and credential phishing. A spoofed clone of your sign-in flow cannot talk to the real backend, so harvested credentials have nowhere to go. 

Platform SDKs, Console, and CLI 

Native client SDKs ship for iOS (Swift), Android (Java), Web (JavaScript / TypeScript), and Hybrid (Flutter), and align with the Firebase SDKs wherever practical. A bundled Console handles app registration, user management, App Trust providers, Security Rule editing, data browsing, Storage setup, Vector Columns, Authorized Domains, and project management. A CLI (fusabase) handles project setup, configuration, and scripted workflows from the terminal. 

For Firebase Developers 

The Fusabase SDKs are designed to feel familiar to Firebase developers. Concepts like collections, documents, queries, auth state listeners, security rules, and storage references have direct equivalents. The toolkit is not a 1:1 reimplementation of Firebase, but the day-to-day shape of building an app on it is close enough that existing Firebase code patterns translate directly — even when the backend is Oracle AI Database. 

Available Today 

Oracle Backend for Firebase is generally available today as part of ORDS 26.1.1. It runs everywhere ORDS runs — Oracle Cloud Infrastructure, AWS, Azure, Google Cloud, on-premises, Cloud@Customer, or any environment your team already deploys ORDS into. There is no separate service to subscribe to, and no new operational surface to learn. 

To get started: 

Shape What’s Next 

Oracle Backend for Firebase ships today as a complete toolkit, and we’re working directly with the teams building apps on it. If you’re starting a new app on Oracle AI Database and want a direct line to the product team while we shape what comes next, tell us what you’re building. The capabilities, ergonomics, and integrations that ship next will be guided by the apps actually using Fusabase. 

Feel free to reach out, my email and DMs are open: