IceBase keeps Firebase's API and makes the backend a swappable config value

A developer has released IceBase, an Apache-2.0 licensed library that preserves Firebase's API while turning the choice of backend into a configuration setting. According to a post by Panth Patel on dev.to, each service in an application can run against real Firebase, a self-contained emulator backed by SQLite, or a self-hosted server on Postgres, with the same application code working across all three. The project is at version 0.6.0, published on JSR, with its source code on GitHub.

Same calls, one extra file

Patel's motivation is the moment a side project stops being one. When an app had to run for a company or at scale, he writes, there was no quick exit: the code was written against Firebase's SDK, and the data model was implicit in whatever the database happened to contain.

IceBase keeps Firebase's function names and call shapes, so adopting it mainly means changing imports. The one difference developers will notice is key paths: nested fields are addressed with arrays rather than dotted strings, because a dotted string would be read as a single key. A new file, icebase.config.ts, holds the schema, rules, functions and hosting configuration, and sets the mode of each service per environment — for instance, emulator locally and firebase in production.

The schema is the centerpiece

Patel describes the declared schema as the real feature. Firebase accepts documents of any shape, which makes it fast to start with but leaves nothing to review; he argues this bites harder now that AI writes much of the code, since a developer checking that output still needs interfaces and a schema to inspect.

IceBase asks for the exact shape of every collection, Realtime Database path and storage path, plus every field a query filters on. Writes are type-checked and validated at runtime in all modes, and a query whose index has not been declared fails at compile time and is refused at runtime. A CLI check lists every such query so it can be caught in CI.

For projects that already exist, an init command drafts a schema from a sample of documents, and a learning mode reports undeclared collections and missing indexes instead of rejecting them outright.

Three backends, mixed per service

The firebase driver uses the real Firebase SDKs with IceBase's type, schema and index checks layered on top. The emulator mode runs Patel's own server on SQLite — built, he says, because Firebase's official emulator felt slow and he wanted something suited to production-like testing — and it enforces security rules written in Firebase's own syntax, so the same rule files deploy to Firebase unchanged. The vm mode runs that same server on Postgres, self-hosted.

Modes can differ per service, so one service can move while the rest stay on Firebase, and a single migrate command transfers data between the SQLite and Postgres stores in either direction. IceBase also ships its own console that works in every mode. Conformance suites run against Firebase's emulators, the IceBase server and a live Firebase project, and every IceBase-server suite also passes on Postgres. Patel's design tool, Digital Canvas, runs on IceBase in firebase mode.

What is not built yet

The post is frank about the gaps. Stored files in vm mode stay on disk, S3 support is not built, and the migrate command does not copy files. There is no Docker image, no login-and-deploy flow for a VM, and no backups. Import, export and link — the features that would turn leaving a live Firebase project into a one-command job — are next on the roadmap. Patel is explicit that a fast, painless exit is the goal, not a claim about the current release.

Why it matters

Lock-in with Firebase usually bites in the data-access layer: leaving means rewriting SDK calls and reconstructing a data model from live documents. IceBase's bet is that developers adopt it on day one, while Firebase is still the right choice, and keep a way out as a per-service setting — the same API, an Apache-2.0 license, and a schema that has lived in the repository all along, ready for the day Postgres becomes necessary. At v0.6.0, with the migration tooling still on the roadmap, it is not a finished escape hatch, but the model of backend portability as configuration is a practical one for teams that want the option to leave before they actually need it.