We did not arrive at Firebase as our default backend through ideology. We arrived at it through a series of projects where it was genuinely the right tool, and a developing sense of where its characteristics align well with the specific demands of AI-integrated applications.
This is an honest account of why we use it, what we give up, and when we do not.
Real-Time Is Not Optional for AI Features
AI inference takes time. Users experience this wait. How you handle the wait has a significant impact on how the feature feels — which determines whether users actually use it.
Firestore's real-time listeners make it straightforward to stream progress and results back to the client as they become available. You write intermediate state to a Firestore document from a Cloud Function while the inference runs; the client subscribes and updates the UI progressively. The user sees the response building rather than staring at a spinner. This pattern — async inference with real-time progress — works naturally with Firestore and requires significantly more infrastructure with a traditional REST API.
Cloud Functions Handles the Integration Layer
Most AI applications are integration problems as much as they are modelling problems. You need to call an external inference API, handle its response, write results to storage, trigger downstream actions, send notifications. You need rate limiting, retry logic, and dead-letter queues for when things fail.
Cloud Functions v2 handles this well. Firestore triggers (on document create/update) give you a clean event-driven architecture for processing pipelines. The function runs when data arrives, not on a schedule. For processing workloads — transcription, embedding generation, classification — this pattern is more efficient and easier to reason about than polling.
The Serverless Constraint Is Usually an Asset
Cloud Functions have execution limits. They are stateless. They are not suitable for long-running processes. For conventional applications, these constraints are occasionally limiting. For AI applications, they are usually fine — inference is typically a bounded operation, and statelessness maps naturally to the request-response pattern of most ML workloads.
Where they are not fine: long-running training jobs, model serving that requires persistent GPU state, streaming inference with sessions that span minutes. For these, we use dedicated compute — typically a Cloud Run service with a GPU-attached container, orchestrated by the Cloud Functions that trigger it.
The Operational Overhead Argument
A conventional self-hosted backend requires infrastructure management: provisioning, scaling, patching, monitoring. For a small firm shipping client projects, this overhead has a real cost. Firebase eliminates most of it. Firestore scales without intervention. Cloud Functions handle load automatically. Firebase Hosting serves the Next.js static export through a global CDN without configuration.
This means the engineering time that would otherwise go to infrastructure operations goes to the product. For the kinds of projects we ship — custom AI integrations for mid-market businesses — this trade-off is usually favorable.
Where We Do Not Use Firebase
For applications with complex relational data models — many-to-many relationships, complex joins, transactional integrity across many entities — a relational database is more appropriate. Firestore's document model encourages denormalization, which works well until you have data that genuinely needs to be relational.
For applications that need SQL analytics directly against operational data, BigQuery is the better choice — and we frequently use both: Firestore for operational reads/writes and real-time subscriptions, BigQuery (populated via streaming export) for analytical queries. The inventory management system we shipped in November uses exactly this architecture.
The Honest Summary
Firebase is not the right answer for every problem. It is the right answer for a specific class of problems: real-time client applications, event-driven processing pipelines, serverless integrations, and teams where operational simplicity has a real value. That class of problems happens to cover most of what AI-integrated applications require. That is why it is our default.