Firebase Realtime Database to MongoDB: How to Move Your Data

Syncing Firebase to MongoDB moves application data from one document store to another, usually as part of migrating off Firebase or feeding a MongoDB-backed service with data an app already writes to Firebase. Airbyte will do it with no code. Both systems hold documents, which makes this sound like a straightforward copy, and it is worth understanding why it is not.

Each end applies its own transformation. Firebase emits a key and a JSON value rather than a document, and the MongoDB destination then wraps whatever it receives in an envelope. Your data passes through two layers before it lands.

What your documents look like on arrival

The Firebase Realtime Database source emits records with two fields: the key, which is the node's identifier in the tree, and the value, holding that node's contents as JSON.

The MongoDB destination then writes each stream to its own collection, where every document holds three fields: an _id assigned by Airbyte as a String, an _airbyte_emitted_at Timestamp, and _airbyte_data as an Object holding the record.

Put those together and the result is nested twice. Your Firebase node's contents sit inside the source's value field, which sits inside the destination's data object. An application reading the target collection has to traverse both layers, and the Firebase key that identified the node is not the collection's identifier, since Airbyte assigns its own.

This is the single most important thing to know before building. If you were expecting your Firebase documents to appear in MongoDB looking as they did in Firebase, ready for an application to query, they will not. Plan a transformation step in MongoDB that unwraps both layers and writes clean documents into a second collection, and point applications at that.

For a genuine migration where the target must be a drop-in replacement, a purpose-built export and import is a better instrument than a replication pipeline. Airbyte is good at landing the data somewhere for processing, which is a different job.

Choosing a sync mode

The destination supports full refresh and incremental append, along with namespaces, and does not support incremental append with deduplication.

For a one-off migration, full refresh overwrite is right: you want the target to match the source at a point in time, and a clean replacement gives that. For an ongoing feed, the absence of deduplication means an updated Firebase node arrives as an additional document rather than replacing the earlier one, so your transformation step has to select the latest version using the emitted timestamp. Build that into the design rather than discovering it when counts start drifting.

Setting up both ends

On the source, create a Google Cloud service account with the Firebase Realtime Database Viewer role, and generate a key in JSON format, which is the only format supported. Copy the contents into the connector configuration and delete the file afterwards.

Set the Node Path to the subtree you actually want rather than leaving it at the root. Firebase trees typically hold session state, caches, and denormalised duplicates alongside the entities you care about, and syncing the root brings all of it across. There is also a Buffer Size setting governing how many records are fetched at a time, useful on a large node.

On the destination you need a MongoDB server and a user that can create collections and write documents, ideally created specifically for Airbyte. Choose or create the target database in advance. You can configure a standalone instance with host, port, and TLS, or a replica set by supplying its server addresses. Note that Airbyte Cloud supports connecting to MongoDB only with TLS encryption.

Frequently asked questions

Why are my documents nested two levels deep?

Both ends transform. Firebase emits a key and a JSON value, and the MongoDB destination wraps that in an _airbyte_data object. Unwrap both layers in a transformation step.

Can I use this to migrate off Firebase?

You can land the data, but not as a drop-in replacement. The document shape changes at both ends, so plan a transformation into clean collections, or use a purpose-built export and import instead.

How do I avoid duplicate documents?

There is no deduplicated sync mode on this destination. Use full refresh overwrite where it fits, or select the latest version by emitted timestamp in your transformation.

Does my Firebase key become the MongoDB _id?

No. Airbyte assigns its own String _id, and the Firebase key sits inside the record. Promote it yourself if you want it as the identifier.

Get your Firebase data into MongoDB

Scope the node path, expect two layers of nesting, and plan a transformation into clean collections before any application reads the result. For the same source into a relational database, see our guide to Firebase Realtime Database to MySQL. For loading files into the same destination, see Parquet to MongoDB.

Start syncing now →