A pub/sub platform next to a synced JSON tree. Different shapes, one honest comparison for teams choosing between them.
Firebase Realtime Database is a managed JSON tree that syncs to connected clients. Foony is managed pub/sub messaging over channels. They overlap wherever the goal is "users see changes instantly", and differ everywhere else: Firebase wants to be your database, Foony works beside the database you already have.
When Foony fits
You want messaging semantics: guaranteed per-channel ordering, effectively exactly once delivery, and replayable history. Firebase documents no per-message delivery guarantees, clients converge on current state.
Presence should be built in. On Firebase, who-is-online is a recipe you assemble from /.info/connected and onDisconnect writes.
Your data already lives in Postgres. Database Sync streams live query results to clients without moving your data into a proprietary tree.
Pricing you can predict: messages in and out, nothing else. Firebase bills downloaded bytes including protocol and TLS overhead, which is hard to estimate in advance.
You need to scale past one database. Firebase caps a database at 200,000 connections and 1,000 writes per second, and the official answer beyond that is manual sharding.
End-to-end encryption. Firebase encrypts in transit and at rest, but the service can read your data.
When Firebase Realtime Database fits
You want a persistent state store with offline sync, not a message stream. Mobile SDKs persist data and queued writes across app restarts and converge automatically.
You are already on Firebase Auth and security rules, which give clients direct, rule-checked access with no token backend.
High-volume tiny payloads on a budget: $1 per GB downloaded can be very cheap when messages are small and connections are few.
A hobby project fits the free Spark plan and its 100 concurrent connections.
Model and features
Foony
Firebase Realtime Database
Model
Pub/sub channels with presence, history, and chat on top
A synced JSON tree that clients attach listeners to
Presence
Built in, with automatic re-entry on reconnect
DIY recipe: /.info/connected listener plus onDisconnect writes
History
Per-prefix channel rules, up to 30 days
State persists, but there is no message replay or stream position
Ordering and delivery
Effectively exactly once (idempotent publish, client dedup)
No documented delivery guarantees, clients converge on state
Encryption
End-to-end AES-GCM, key never leaves your clients
TLS in transit and encryption at rest, service can read data
Works with your database
Database Sync streams live Postgres query results
Firebase is the database
Limits
Foony
Firebase Realtime Database
Concurrent connections
Up to 150,000 on the Scale plan, per app
200,000 per database, then shard across databases
Write throughput
Up to 150,000 messages/second on Scale
1,000 writes/second per database
Message size
64 KB free, up to 1 MB on paid plans
16 MB per SDK write (it is a database write, not a message)
Regions
One global endpoint
Three regions, single region per database, fixed at creation
$1/GB downloaded (protocol and TLS overhead included) plus $5/GB-month stored
Entry paid tier
$19/month for 100M messages
Blaze is pay as you go, no fixed tier
Competitor numbers last checked July 2026. If something has drifted, tell us and we will fix it.
Moving over
There is no protocol bridge between a database tree and pub/sub channels, so a migration is a re-mapping: paths your clients listened to become channels they subscribe to, and writes become publishes. When the state behind those paths lives in Postgres, Database Sync gives you the same live-result feel with your own database as the source of truth.
Try it on the free tier
9M messages a month, presence, history, and the Pusher-compatible API are all on the free plan. No card required.