They show up in every architecture thread on the internet. Someone asks about data modeling, event sourcing, or multi-tenant isolation. Within three minutes comes the comment: "Just use Firebase."
My app has complex relational data with joins across 30 tables. "Just use Firebase." I need ACID transactions for financial operations. "Just use Firebase." I'm building an offline-first POS system that syncs with a cloud backend and handles money. "JUST USE FIREBASE."
It has become a reflex. The answer arrives before anyone reads the requirements or looks at the problem.
To be fair, Firebase is more than one database now. Firebase Data Connect puts Postgres behind it, with real relations and joins. My complaint is about Firestore and the Realtime Database handed out as the default answer to every data question.
The offline-first POS shows where that default hurts. A sale on a terminal without internet is money that already changed hands. The order, the payment and the stock change have to be written locally in one transaction. When the terminal comes back online, the server has to accept that sale exactly once, and the end-of-day totals have to reconcile with what the payment side says happened. If two terminals changed the same stock or the same tab while offline, the conflict needs an explicit rule someone can audit later. Last write wins on a document is the wrong rule for money. With a document store and its offline cache, most of this becomes code you write and test yourself.
Firebase is great for prototypes, hackathons, that side project you will abandon in two weeks, and data that maps cleanly to documents. When the data model needs joins, transactions across many records, or totals that must reconcile at the end of the day, start from a relational database: Data Connect if you want to stay in Firebase, Postgres anywhere else.