Firebase Realtime Database to Convex: How to Move Your Data

Moving Firebase Realtime Database into Convex is usually a migration between application backends. Both exist to serve an app rather than to answer analytical questions, so this is about changing where your product's data lives rather than about analysis.

This guide covers the managed path with Airbyte. Two things shape the build: the source produces exactly two columns whatever your tree contains, and the second of those columns arrives as text rather than as structure a destination can see into.

Firebase Realtime Database to Convex at a glance:

Why move data from Firebase Realtime Database to Convex?

Two situations account for most of these pipelines.

The first is migration. A team moving its application from one backend to another needs the existing data to arrive in the new one, and doing that with a connector beats writing an export script that somebody then has to maintain through several iterations of getting it right.

The second is seeding a new product surface from data that already exists. What this is not is an analytical move, since neither system aggregates well. If somebody wants to query this data with SQL, Firebase Realtime Database to PostgreSQL turns the tree into something a reporting tool understands.

What do you need before you start?

Four things, and the second is a decision you should make deliberately:

A service account with the Firebase Realtime Database Viewer role. Plus a JSON key, which Airbyte supports exclusively. Download it at creation since that is the only moment Google shows the contents, and delete it locally once configured. The Firebase Realtime Database source documentation walks through both.

A node path per logical entity. The connector syncs one path per source and defaults to the root, which pulls your entire tree into one undifferentiated stream. Name the subtrees you actually want instead.

A Convex deployment, and awareness of what it is. The destination is in beta and import only, so there is no Convex source to bring this data back out through Airbyte later. Table naming rules apply, so check yours before the first sync.

A plan for reshaping the data after it lands. Because of the two-column output described below, what arrives is not yet the document model your application wants, and turning it into one is your work rather than the pipeline's.

If your organisation restricts access by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.

How do you build a Firebase Realtime Database to Convex pipeline in Airbyte?

Step 1: Scope the node paths before configuring anything

Look at your tree and identify the subtrees that correspond to distinct things, such as users, orders or sessions. Each becomes its own source and its own destination table, which maps far better onto an application than one enormous stream from the root does. The default really is the root, so leaving the path empty is a decision rather than an omission, and it is rarely the one you want.

Step 2: Configure the Firebase Realtime Database source

Click Sources in the left navigation, then New Source, and select Firebase Realtime Database, following adding a source. Supply the database name, the contents of your service account key and the node path. Buffer size controls how many records are fetched at once and is the setting to reduce if a large node causes memory pressure. Repeat per path.

Step 3: Configure the Convex destination

Click Destinations, then New Destination, and select Convex, following adding a destination. Supply your deployment details and access key. Check your table names against Convex's naming rules now rather than discovering a rejection partway through a migration you have scheduled.

Step 4: Create the connection and plan the reshaping

Click Connections, then New connection, select the stream and a sync mode. Only full refresh is available, so each run is a complete picture of that node, and on a large tree that is worth testing for duration before you depend on it during a cutover.

Then write the function that turns what landed into the documents your application expects, because nothing upstream does that for you.

Why is the output only two columns?

Because Realtime Database has no records or tables to describe. It stores one large JSON tree, so there is no schema for a connector to reflect, and the honest response is a shape that works for any tree at all: a key column holding the key of each fetched object, and a value column holding a string representation of whatever that key pointed at.

The important word there is string. The value is not a nested object that a destination can look inside; it is text that happens to contain JSON. A user record with an address and an age arrives as one key and one string, and any structure it had is preserved as characters rather than as fields.

That makes the node path your only real modelling lever on the source side. A path scoped to one entity produces a stream where every value has the same shape, which is straightforward to parse on the other side. A path at the root produces a stream where values are whatever happened to be at each top-level key, which is considerably harder to do anything with.

What does Convex actually receive?

Documents with a key and a string, which is not the document model you are migrating towards. Convex is built around structured documents its functions query and validate, and a table whose interesting content is trapped inside a text field gives you very little of that. The data has arrived; the modelling has not.

So treat what lands as a staging table rather than your application's schema. Write a Convex function that reads those rows, parses the value, and writes properly structured documents into the tables your app actually uses. That is a modest piece of work and it is the step that turns an import into a migration, which is the thing you were doing.

Two constraints to keep in mind while planning it. The destination is import only, so there is no Airbyte route back out of Convex if you need to reverse course, which argues for keeping Firebase intact until the migration is proven. And full refresh on a large tree takes as long as it takes, so rehearse the timing before a cutover rather than discovering it on the day.

Frequently asked questions

Why are there only two columns?

Realtime Database stores a JSON tree rather than records, so there is no schema to reflect. You get a key and a string representation of the value at that key.

Can Convex query inside the value?

Not usefully, since it arrives as text rather than structure. Parse it in a Convex function and write properly shaped documents into your application's own tables.

Can one source cover my whole database?

It can, since the path defaults to the root, and it rarely helps. One source per meaningful subtree gives you streams whose values share a shape.

My sync struggles on a large node.

Reduce the buffer size, which governs how many records are fetched at a time, and narrow the node path so you are not reading subtrees you do not need.

Can I do this without writing code?

The pipeline, yes. The Convex function parsing the value column into real documents is code, and without it you have imported text rather than migrated an application.

Get your Firebase Realtime Database data into Convex

Scope your node paths so each source covers one kind of thing, because the path is your only modelling lever and the default is the entire tree. Expect two columns, with the value arriving as text rather than structure. Then write the Convex function that parses it into real documents, and keep Firebase running until that is proven, since the destination is import only and there is no route back through Airbyte.

Airbyte's connector catalog includes 600+ pre-built connectors, so an application's data can change backends without a bespoke export script. For the same source into another document store, see Firebase Realtime Database to MongoDB, and for analytical results into the same destination, ClickHouse to Convex.

Start syncing now →