Firestore Admin GUI: Manage Firestore Data Without the Console
Updated
Cloud Firestore has no built-in desktop client like a SQL database does. For most teams, the Firebase console is the default Firestore admin GUI, and it's fine for a quick look. Once you work with your data every day (debugging production records, fixing a bad write, seeding a new environment), its limits start to cost real time. This guide covers what a good Firestore admin GUI should do, the options available, and how to choose one safely.
What the Firebase console does well
- It's already there, with no setup, and it respects your Google Cloud IAM permissions.
- It shows collections and documents, supports a query builder, and edits individual fields with their types.
- It manages indexes, rules, backups, and usage, which data tools don't try to replace.
Where it gets in the way
- Editing is field by field. Changing several fields, or pasting a whole document, means many clicks.
- No JSON import or export. Managed exports go to Cloud Storage in a binary format; getting a collection as JSON needs a script.
- No undo. A deleted document is gone unless you've set up backups or point-in-time recovery.
- No read-only mode. Browsing production carries the same risk as editing it.
- Large collections are awkward to page through, sort, and count.
Your options
| Approach | Good for | Watch out for |
|---|---|---|
| Firebase console | Quick looks, indexes, rules | Slow bulk edits, no JSON |
Admin SDK or gcloud scripts | Repeatable migrations | Writing and reviewing code for every one-off task |
| Desktop GUIs | Offline-style workflows | Most need a service-account key file on your machine |
| Web GUIs such as Firewatch | Everyday browsing and editing | Check how they authenticate and where your data flows |
What to look for in a Firestore admin GUI
1. How it gets access
This matters more than any feature. Many tools ask you to create a service account and upload or store its JSON key. A key like that grants standing access to your whole project and is easy to leak. Prefer tools that act as you, using a short-lived Google OAuth token and your existing IAM role, so they can't do anything you couldn't already do in the console. See Firestore IAM roles for how that access is controlled.
2. Where your data goes
Some web tools proxy every request through their own servers, which means your production data and credentials pass through a third party. The safer design has your browser call Google's API directly.
3. Type fidelity
Firestore has types that plain JSON doesn't: timestamps, document references, geopoints, bytes, and 64-bit integers. A careless editor turns a timestamp into a string or rounds a large integer, and your app breaks in subtle ways. Read how to edit Firestore documents safely for the details.
4. Safe writes
Look for confirmation on deletes, some form of undo, and protection against overwriting a document someone else changed after you opened it.
5. Scale
Cursor-based pagination, server-side counts, and filters that run in Firestore, not in the browser, keep large collections usable and your read bill predictable.
Using Firewatch as your Firestore admin GUI
- Sign in with the Google account that has access to your Firebase projects.
- Choose Connect Project, allow Firewatch to list your projects, and pick one and its databases.
- Open a collection to browse it as a table, filter and sort, and click a document to view or edit it.
- Use Export and Import to move collections as JSON, and the Read-only switch when you only want to look.
Firewatch calls Firestore directly from your browser with your own token, so your data never passes through our servers, and there are no keys to create. The features page lists everything it does.