💡 Target Audience: Startups and Indie Hackers who got burned by Firebase's massive Read/Write Document operation costs.

The unit mismatch: documents vs. fan-out

Firestore is an excellent document database. Chat is not a document workload — it is a fan-out workload, and that mismatch is where the bill comes from.

A document database bills the operation *per document touched*. Chat delivers one message to many people. So the cost of a conversation scales with participants × messages, not with messages.

Watch the multiplication:

Same conversation volume. 100× the operations, purely because more people are listening.

Now add the features users expect. Typing indicators write a document per keystroke burst and are read by every participant. Read receipts write per member per message. Presence updates on every foreground/background transition. Each of these is individually reasonable and collectively multiplicative — a 1,000-member room can generate more billable operations from *metadata* than from messages.

We are deliberately not printing a dollar figure here, because per-operation rates vary by product, region and tier. Take your own reads-per-100K rate from the current pricing page and multiply by the table above. The number is usually the surprise, not the rate.

Why HyperBabel does not have this curve

HyperBabel is built for fan-out. Delivering a message to 999 subscribers is one logical publish, not 999 billable reads. Presence, typing indicators and receipts are transport-level primitives rather than rows you write and everyone re-reads.

That changes what you are billed for:

• Peak concurrent connections (your plan tier) — Scale covers 1,000. It is a contractual limit, not a kill switch.
• Messages sent, not messages read — 10M included on Scale, then $7.99 per 1M.
• Active channels — 5,000 included on Scale, then $9.99 per 1,000/month.
• Typing indicators, presence and receipts are not separately metered at all.

The practical difference: on a per-operation database, a highly engaged group chat is your most expensive customer. On HyperBabel, it is just a busy channel.

When Firebase is genuinely the better choice

Firebase is the right answer more often than chat-platform vendors like to admit:

• Prototypes and MVPs. If you are validating whether anyone wants the feature, Firestore is faster to ship and the bill is trivial at low volume.
• Small rooms. 1:1 and small-group chat (under ~20 members) never triggers the fan-out curve. The math above simply does not apply to you.
• Offline-first apps. Firestore's local cache and offline sync are genuinely excellent and non-trivial to replicate.
• Chat is a minor feature. If messaging is a small corner of an app already built on Firebase, adding a second platform may cost more in complexity than it saves in operations.

You do not have to choose one vendor for everything

The most common good outcome is not a migration — it is a split:

• Keep Firebase for authentication and app data. It is good at both.
• Move the fan-out workload — messages, presence, typing, receipts — to a platform billed by traffic.

HyperBabel's Customer Auth accepts a Firebase ID token directly and mints per-end-user access tokens, so your users keep signing in exactly as they do today and your client never holds a platform API key. You keep the Firebase console you already know; you stop paying per read for other people's messages.

Migration checklist

1. Measure ops, not dollars, first. Pull reads/writes for the last 30 days and split them by collection — messages vs. typing vs. presence vs. receipts. The ratio tells you the whole story.
2. Identify your top 10 rooms by member count. Fan-out cost concentrates brutally; often a handful of rooms drive most of the bill.
3. Move presence and typing first. They are ephemeral, need no backfill, and often deliver the largest immediate reduction.
4. Then move messages, routing new conversations to HyperBabel while old threads stay readable in Firestore.
5. Keep Firebase Auth. Wire Customer Auth to your existing Firebase project so nothing changes for users.
6. Backfill history in batches, oldest first, verifying per-room counts.
7. Watch the ops graph, not the invoice, during the first week — operations fall before the billing cycle reflects it.

The 30-second version

Firestore charges per document touched; chat touches one document per listener. That is not a pricing flaw, it is a workload mismatch — and it stays invisible until your rooms get big. Check your reads-to-writes ratio today. If it is over 50:1, you are paying for fan-out on a database that was never designed to sell it cheaply.