Retool Firestore Multiple Databases: Workarounds & What to Know

If you're trying to connect Retool to multiple Firestore databases and keep hitting a wall, you're not alone. The Retool Firestore resource currently only connects to the (default) database in your Google Cloud project. There's no field in the resource configuration to specify a different database name — and as of now, this is a known, unresolved limitation with no official fix on the roadmap. Here's everything you need to know, including what workarounds have been attempted and what your options look like today.

Why Retool Only Connects to the Firestore Default Database

Google Cloud Firestore supports multiple named databases within a single project — a relatively recent addition to the platform. However, Retool's built-in Firestore resource integration was built around the original single-database model, where (default) was the only option. The resource configuration UI doesn't expose a database ID field, meaning Retool hardcodes the connection to your project's default Firestore database.

This is a blocker for any team that has adopted a multi-database Firestore architecture — whether for environment separation (dev, staging, prod), tenant isolation, or data domain separation. If your app data lives in a named database like my-app-prod or tenant-xyz, Retool simply won't reach it through the standard Firestore resource.

Is This on Retool's Roadmap?

As of the most recent updates in the Retool community forum, this feature is not currently on the roadmap. Retool's team has acknowledged the request, logged it internally, and has been collecting upvotes from affected users. Multiple teams have reported it as a "major blocker," but no timeline has been given for when named database support will be added to the Firestore resource configuration.

If this is blocking your team, the best thing you can do right now is add your voice to the community thread so Retool's product team can see the demand. Feature prioritization is often driven by volume of user impact.

Workarounds for Connecting Retool to a Non-Default Firestore Database

There's no clean, fully supported workaround yet — but here are the approaches that have been explored by teams running into this limitation:

Option 1: Use the Firestore REST API via a Retool REST Resource

Google Firestore exposes a REST API that accepts a database ID as part of the URL path. The base URL pattern looks like this:

https://firestore.googleapis.com/v1/projects/{project_id}/databases/{database_id}/documents/{collection}

To try this approach in Retool:

• Create a new REST API resource in Retool (not a Firestore resource).
• Set the base URL to https://firestore.googleapis.com/v1/projects/YOUR_PROJECT_ID/databases/YOUR_DATABASE_ID.
• Configure authentication using a Google OAuth 2.0 token or a service account key with the appropriate Firestore permissions.
• In your queries, append /documents/YOUR_COLLECTION to the path and use GET, POST, or PATCH methods as needed.
• Parse the Firestore REST response format manually — it returns a structured JSON with field type wrappers (e.g., stringValue, integerValue) that you'll need to transform in a transformer or JavaScript query.

This approach has been attempted by users in the community thread, with mixed results. The main challenges are authentication complexity and the verbose Firestore REST response format. It's workable for read-heavy use cases but can get cumbersome for writes.

Option 2: Proxy Requests Through a Backend Function

If you have a backend (Node.js, Python, etc.), you can expose a simple API layer that talks to your named Firestore database using the Firebase Admin SDK, then connect Retool to that API via a REST resource.

• Use the Firebase Admin SDK and initialize it with your target database: admin.initializeApp({ databaseURL: '...' }) and use admin.firestore().collection('...') pointed at the named database.
• Wrap your Firestore reads and writes in HTTP endpoints (e.g., Express routes).
• In Retool, create a REST API resource pointing to your backend URL.
• Call those endpoints from your Retool queries just like any other REST resource.

This is the most reliable workaround but adds infrastructure overhead. It's worth considering if you're already running a backend service for your internal tool.

Option 3: Migrate Non-Default Data to the Default Database

If your use of multiple Firestore databases is for environment separation and you're building a purely internal tool in Retool, it may be worth restructuring. Using top-level collection prefixes (e.g., prod_orders, staging_orders) or Firestore's native multi-tenancy patterns within the default database can sidestep the limitation entirely.

This isn't always feasible — especially if the multi-database architecture is driven by security rules or organizational requirements — but it's worth evaluating if you have flexibility on the data model side.

What to Do Right Now

• If you need a quick read-only solution: Try the Firestore REST API via a Retool REST resource. It's imperfect but functional for simple queries.
• If you need full read/write reliability: Build a lightweight proxy API using the Firebase Admin SDK and connect Retool to it.
• If you can restructure your data model: Consolidate into the default Firestore database using collection naming conventions.
• In all cases: Upvote the feature request on the Retool community forum to accelerate native support.

Native support for Retool Firestore multiple databases is the right long-term fix. Until Retool ships it, these workarounds will get you unblocked — even if they require a bit more setup than the standard resource configuration.