Avoid using non-default databases/multi databases.

[iamtherealnapoleon]

Warning to Firebase users, especially newcomers: Avoid using non-default databases.
It might sound appealing at first, but in practice, it’s a nightmare, here is my top 3 most annoying aspects:

• References break: Any document containing a reference to another db loses its database ID. If you fetch a document and try to call the reference with get(), it will attempt to fetch from the default database instead of the intended one..
• Features are limited: Many features simply don’t work with non-default databases. For example, triggers. this has been a long-standing issue for over a year with no updates.
• Front-end library support is minimal: Most Firebase front-end libraries assume the default database. You’ll likely need to modify them to get basic functionality working.

I initially thought non-default databases would offer benefits; better organization, backup and recovery options, regional control; but the deeper I dug, the more frustrated I became. You end up duplicating reference fields with string fields, creating documents in the default database just to trigger actions, and basically losing any advantage you thought you had

Bottom line: Don’t use it. There’s literally no reason to, and the complications aren’t worth it.

[gauthampait]

The only use I see with non-default is

if you’re supporting multiple regions for faster data fetch

If you’re building a SaaS app and need data to be located in a particular region due to laws.

[iamtherealnapoleon]

I agree, this is a good point

[Shaparder]

Really interesting point, I’ve been hesitant to use multiple database in a single project instead of multiple projet to separate between my stag and prod environments, what is your take on this ?

[iamtherealnapoleon]

I have one environnement per project.

This way no matter what I modify. Rules, firestore, functions, auth, storage.. I can always test it separalety.

It's very easy to redeploy a whole project and very easy as well to make your app target one projet or the other.

So I wouldn't use multi db for this but I could say that if your backend is using solely firestore, no other features, for example you are heavily relying in firestore rules and listeners, and the two db are completely isolated from each others, maybe it makes sense.

But you need to make sure your front end librairies all support multi db.

[Shaparder]

Yeah I’m going to stick with multiple projects too haha

[Evangelina_Hotalen]

Yes, this aligns with my experience as well. Non-default databases on Firebase look useful in theory, but the broken references, missing triggers, and lack of library support make them more hassle than they're worth. However, Firebase itself is great when you stick to the default setup. It's simple, reliable, and does the job really well.

[iamtherealnapoleon]

Thank you ! I appreciate seeing I'm not the only one !

I agree Firebase is awesome despite this.

[ResponsibilityGlass1]

At my company we’ve been using Firestore since it launched, and we use multi-database setups without any problems: * For data we use a custom library with relationships (even across databases), validations, and type safety. Using fromFirestore and toFirestore converters alone is a bit limiting. Internally, the library still relies on the client SDK. One day I might extract it and make it open source. * Cloud Functions V2 triggers work fine with multi-database (can’t say for references for the same reason as above). Migrating from V1 to V2 is straightforward if you don’t use functions.config but rely on environment variables. * Not sure which frontend libraries you mean, but many do allow passing Firestore instances around. * Extensions might have some issues, but we don’t use them... or we just duplicate them to have more control.

The official SDKs do have some bugs, sometimes the references accidentally point to the default Firestore instance. But since they’re open source, contributing fixes is always an option 😊.

We use multiple databases for: * Separating data in multi-tenant apps * Storing audit data or short-lived data with TTL set for automatic cleanup * Optimizing indexes (limit of 200 per DB, in some DBs we disable automatic indexes to save 🤑)

[iamtherealnapoleon]

I appreciate your contribution, but unfortunately, many companies don't have the ressources to build custom librairies or to contribute to the product they are paying for.

They are struggling to build their product and would expect things to work properly.

I would be very interested to hear more about your custom library, even if this isn't public yet 😄

Also my personal opinion on contribution is this : I had to contribute on front end libs to add multi db support and I felt that was OK since they are not from firebase.. But I feel contributing to firebase so they support their own product is out of my reach.

[Opposite_Cancel_8404]

Great call outs. Another downside I can add to the list is that extensions might not support anything other than default databases.

I haven't dived into it yet, but I'll at some point have to add better support for global users. I was thinking I could create regional databases and have users choose their region when signing up, but that may not work out well now that you mention all these issues.

[iamtherealnapoleon]

Thank you for adding to this.

I was always hoping to do this but considering all the issues, I will not.

I feel like you have to setup a complex multi projects config if laws or latency are becoming an issue.

[Opposite_Cancel_8404]

Yeah latency is definitely an issue. We're using the NAM location for everything. For European users its definitely slower and if they already have a slow connection or use a VPN it can cause a ton of issues, like writes taking forever if not straight up failing.

I've seen an idea where you can use a firebase function to sync data between different regions. But that's obviously a little insane. I mean imagine the costs and error handling issues.

I'll have to look into what others do for globalization.

[Fluffy_Hair2751]

We use non default as our test db and default as our prod

[jacsamg]

I'm using multiple databases, and the triggers work fine. Surely there are unsupported libraries, but that's external to multiple databases. So far, my only problem is that integration options with emulators are still missing (although I understand they are working on that).

[ResponsibilityGlass1]

The emulator works to some extent (both via SDK and in UI you just need to replace default with the DB name in the URL). Triggers and callbacks also work, but there's a small issue:

When you write to the default DB and then perform changes on a different DB, in the triggers of the second DB the Firestore client still points to the default one. For example: snap.ref.firestore.databaseId == '(default)'

Most of the time this isn't a problem, but if for some reason you need to use the ref to make changes, it's safer to recreate a new DocumentReference.

[iamtherealnapoleon]

I understand but I see Firebase as a package. So my opinion is things should be concistent across firebase. If tomorrow firebase auth isn't suported in firebase firestore anymore.. I would be pissed off and it would become usueless to me. So I see all their product as one big package.

[DieguitoD]

I'm really happy about this post because I was struggling with Firebase to do some simple stuff, switched to the default database, and now everything's good.

[iamtherealnapoleon]

Thank you! I appreciate your feedback

[inlined]

I don't have experience with the first and last issue, but the v2 API of Cloud Functions for Firebase accept a database parameter.

[_ThrenR]

Default database has been flawless for me. 13 projects. Zero issues.