Your Firestore data, live in Postgres.

Fireloom is a hosted service that keeps a PostgreSQL database in sync with Google Cloud Firestore in real time. Every insert, update and delete, including subcollections at any depth, lands in one Postgres table within seconds, so you can query your Firebase data with SQL. There's no code to deploy and no Cloud Functions to write.

Free covers 1 sync and up to 100,000 documents per Firebase project, with no credit card. Pro is $29 a month for 10 syncs and unlimited documents. Team is $99 a month for 50 syncs, unlimited documents and priority support. Prices are in US dollars.

Cloud Functions triggers are code you write and run: the schema, a backfill, retries, ordering and deletes are yours to handle, with a trigger per collection path. Batch ETL tools usually re-read whole collections on every run, because Firestore has no change cursor. Fireloom streams changes within seconds, reads only what changed, resumes from checkpoints after restarts, and needs no code. See the comparison.

Yes. Ask Claude Code, Codex, Cursor or another coding agent to “set up Fireloom to sync my Firestore to Postgres”: you approve it once in your browser, and it connects Firestore and your database, starts the sync and shows you the SQL. Claude, ChatGPT, Cursor, VS Code and Codex can also add Fireloom's MCP server, fireloom.io/mcp, to set up and check on syncs. See AI agents.

No. Reading needs only the read-only Cloud Datastore Viewer role. If Fireloom takes the first export for you (the default), setup also adds an export-only role, which can start exports but never imports, and a Cloud Storage bucket of its own. Neither can change your Firestore data. In Postgres it only writes to tables it created; each one carries a marker comment, and Fireloom refuses to touch any table without it.

Usually within a second or two. Fireloom keeps a Firestore listener open for each collection and applies every batch of changes to Postgres in a single transaction.

They're deleted from Postgres too, both while streaming and during consistency checks. After a restart or outage, Fireloom catches up on everything it missed, deletes included.

One table, documents, with one row per document from every collection at every depth: path (the full document path, primary key), collection, id, parent_path, data jsonb, create_time, update_time and synced_at. Filter with collection = 'orders', query fields with data->>'field', or build views and indexes on top.

Any PostgreSQL reachable from the internet: Supabase, Neon, Amazon RDS and Aurora, Google Cloud SQL, Azure, Render, Railway, Crunchy Bridge, or your own server. We recommend a dedicated role that owns the target schema.

The first sync reads each document once, or not at all if you start from a recent Firestore export you already have. After that only changed documents are read, including after restarts: Fireloom resumes where it left off instead of re-reading. A daily consistency check compares document counts (about one read per 1,000 documents) and re-reads only if they differ.

Yes, all of them, at every depth: users/alice/orders/o1/items/i1 is synced just like users/alice, even when a parent document doesn't exist. They land in the same documents table, and parent_path joins each row to its parent. A subcollection with a brand-new name is picked up at the next daily consistency check, or right away when you press Resync.

Service account keys and connection strings are encrypted with AES-256-GCM before they're stored and are never returned by the API or shown again. Fireloom refuses connections to private network addresses.

Fireloom's server is in Nuremberg, Germany (EU). It reads from your Firestore and writes to your Postgres; documents pass through it in memory and aren't stored there. Fireloom stores your account, your encrypted connection settings and sync history. See the privacy policy for details.