Which open-source option replaces Firebase Realtime Database
If your renewal, Blaze bill or connection limits have pushed you to look at Firebase Realtime Database alternatives, the short answer is this: Supabase Realtime over Postgres is the closest fit when you want relational data and SQL, Appwrite Realtime fits teams that want a Firebase-shaped product set (auth, databases, storage, functions and realtime in one stack), and PocketBase suits smaller apps that can live with a single server and embedded SQLite. The choice usually turns on how your data is shaped and how many persistent connections you expect, not on the realtime feature alone. Firebase's migration tooling for Firestore does not cover the Realtime Database, so treat this as a separate workstream with its own export and rebuild.
Realtime Database stores one JSON tree, and most teams have nested objects and denormalized copies that were designed around listeners on specific paths. Moving that data to Supabase means defining tables, foreign keys and indexes, then deciding which listeners become subscriptions to table changes filtered by row. Appwrite's built-in Firebase migration lists the Realtime Database among the items it does not move, so plan to export the JSON, write a transform and load it yourself or with a script. Appwrite's Realtime service is documented in its README, and PocketBase realtime subscriptions are documented on its docs site. Confirm the subscription model, filter syntax and per-connection behavior for your chosen platform against its current documentation before you commit.
Connection scaling is the decision most likely to surprise you. Supabase Realtime runs as one service in the Docker configuration, and its version is pinned in each release, so the sizing you test should match the version you deploy. Appwrite's installation guide and Helm chart docs describe a single-replica built-in datastore, so persistent connections at scale need managed or operated Redis and PostgreSQL. PocketBase's FAQ says it scales only vertically on one server, though it reports 10,000+ persistent realtime connections on a small VPS. Load test with your real subscription pattern, record the results, and ask the vendor or community which settings govern concurrency before you size production.
How Realtime Database capabilities map to open-source options
This table maps the main Firebase Realtime Database capabilities to Supabase Realtime, Appwrite Realtime and PocketBase subscriptions, and flags where parity is partial. Read each row as a question to confirm in the current docs for your chosen version, not as a finished migration plan. The main takeaway is that live sync and triggers map reasonably well, while offline persistence and per-path rules need separate design work.
| Capability | Supabase (Postgres changes, broadcast, presence) | Appwrite Realtime or PocketBase subscriptions |
|---|---|---|
| Live data sync to clients | Postgres changes stream row inserts, updates and deletes over channels; confirm table publication setup and payload size limits. | Appwrite Realtime pushes changes on subscribed channels; PocketBase subscriptions push record changes. Confirm channel names and event types per version. |
| Offline-friendly client listeners | Gap to plan for: no direct equivalent of Firebase's local cache and write queue. Build retry and local state in your client code. | Gap to plan for: confirm whether the SDK caches and replays writes. Expect app-level sync logic in most cases. |
| Presence (who is online) | Supported through Realtime presence on channels; confirm how state is cleared when clients disconnect. | Confirm whether Appwrite or PocketBase provide presence natively. Many teams track it in a separate channel or table. |
| Per-path security rules | Postgres row level security replaces path rules; rules must be rewritten as policies on tables, and Realtime must respect them. Test each policy. | Permissions are set per collection, document or bucket. Path-style rules do not translate one to one, so map each rule and test it with real client identities. |
| Server-side triggers on data change | Database triggers and Edge Functions can react to changes; confirm the webhook or function wiring for your version. | Appwrite Functions can be triggered by events; PocketBase uses JavaScript hooks. Confirm event coverage for each record type. |
| Broadcast and ephemeral messages | Broadcast sends messages between clients without writing to tables; a common replacement for short-lived Realtime Database paths. | Confirm whether a broadcast-style pattern is available or must be built on a collection written by the server. |
| Scaling persistent connections | Connection capacity depends on the Realtime service sizing and host resources; load test with your expected concurrency. | PocketBase runs on one server and scales vertically only; Appwrite's Helm chart runs single replicas for built-in datastores by default. Plan load tests. |
| JSON backups and export | Use Postgres backups and table exports; managed backups and point-in-time recovery are not available in self-hosted Supabase. | Confirm the backup approach for your database engine. PocketBase offers dashboard backups stored locally or in S3-compatible storage. |
Choosing between Supabase Realtime, Appwrite Realtime and PocketBase
Each option gives a Firebase Realtime Database team a different trade: a Postgres change stream, a backend that ships its own realtime service, or a single binary with embedded SQLite. The cards compare licensing, data model fit, connection scaling and who maintains each stack, so the choice can be tested against your connection counts and your appetite for operating the platform yourself.
Supabase Realtime on Postgres
Supabase is Apache-2.0 and its self-hosted Docker configuration includes a Realtime service alongside Postgres, PostgREST and Auth. Realtime follows changes in Postgres tables, so a team moving from JSON tree paths must first decide which tables and row level security policies the subscriptions observe. The community support status matters here: self-hosted Supabase is supported through GitHub Discussions, GitHub Issues, Discord and Reddit, so production incidents rely on your own on-call capacity. Confirm the Realtime service's connection limits in your own load test before committing.
Appwrite Realtime with a PostgreSQL default
Appwrite is BSD-3-Clause and includes Realtime in its core service list, so subscriptions sit inside the same platform as Auth, Databases and Storage. New 2.x installs provision PostgreSQL by default, while MariaDB and MongoDB remain supported, which affects how collection-style data maps from Firestore or Realtime Database paths. Appwrite's Helm chart documentation says its built-in datastores run a single replica without failover, so a production realtime deployment should plan for managed or operator-run databases. Ask your team to verify which database engine your target install will use before modeling the data.
PocketBase on embedded SQLite
PocketBase is MIT-licensed and runs as a single executable with embedded SQLite in WAL mode, with realtime subscriptions built in. Its FAQ says it can serve 10,000+ persistent realtime connections on a $4 Hetzner CAX11 VPS, but it scales only vertically on one server and has no plans for other databases. The project's documentation warns that backward compatibility is not guaranteed before v1.0.0 and that it is not recommended for production critical applications yet. It is developed on a volunteer basis with no paid company behind it, so this option fits smaller apps whose scale and risk tolerance match those limits.
Maintenance model and upgrade risk
Supabase's Docker configuration bundles specific upstream service versions, and operators pull and recreate them, so each release needs a test environment and a rollback plan. Appwrite 2.0 replaced the engine underneath, and existing 1.9.x installs upgrade with a migration, so budget time for a dry run. PocketBase may need manual migration steps from its changelog at each upgrade. Ask each vendor or project for its release cadence, security patch policy and the upgrade path from your current version before selecting one.
Connection scaling and hosting shape
Supabase and Appwrite split realtime across several containers, so connection capacity depends on how the gateway, Realtime service and database are sized together. PocketBase concentrates everything in one process, which keeps operations simple but ties capacity to one machine's CPU, memory and disk. Load test your expected concurrent subscriptions, reconnect storms after a deploy and the write rate that drives change events. Record the results so the platform choice rests on measured limits rather than vendor summaries.
Turning a JSON tree into tables and row-level subscriptions
Realtime Database stores one JSON tree, so every path such as /rooms/{roomId}/messages/{messageId} is both the storage address and the unit a client listens to. Moving to Supabase Realtime over Postgres means splitting that tree into tables. Each repeated object type becomes a table with a primary key, and each parent link becomes a foreign key column, for example a messages table with a room_id referencing rooms. Nested maps that only exist under one parent can usually stay as columns, or as a jsonb column if their shape varies. Arrays of IDs in the tree are typically replaced by join tables. The key decision is the primary key and the foreign key choice, because they determine which filters a subscription can express later. The data model detail for document databases is covered in the Firestore sibling topic, so this section stays with the Realtime Database paths.
On the client side, a listener on a path becomes a subscription on a table with a filter, such as a change feed limited to rows where room_id equals one value. Supabase Realtime's Postgres changes feature and PostgREST both respect the table's row level security policies, so the access rules you wrote for the tree must be restated as policies before subscriptions go live. Confirm with the current Supabase documentation which filter operators and event types the Realtime version you pin supports, because the self-hosted Docker configuration bundles its own Realtime release. Appwrite Realtime and PocketBase realtime subscriptions follow the same idea at a different granularity, so test the chosen filters against your access model in each candidate.
Fan-out is the riskiest part of the migration. In the Realtime Database, a listener on a large node receives every change beneath it, and many apps were built around that behavior, sometimes by listening to a parent for convenience. In a table model, a subscription on an unfiltered table that grows to millions of rows delivers far more events than the client needs, and the database must evaluate policies for each change. Redesign listeners so each one watches a bounded set of rows, usually one room or one user, and move aggregate views such as counts into server-side functions or materialized views. Load test the redesigned subscriptions with your expected concurrent connections on your chosen server size, since connection capacity depends on your own sizing and the vendor does not guarantee a figure here.
Running realtime next to the rest of the Firebase suite
Few teams can move realtime in one step. Auth, Firestore or Realtime Database, and client code often stay on Firebase while a subset of features moves, which creates trust and data-consistency questions. The cards below cover what to decide before the first phase goes live.
Where Firebase Auth still runs
If Firebase Authentication stays in place while realtime moves to Supabase or Appwrite, every session token is issued by Google's identity service. Firebase Authentication processes data only in the United States, so user records and token issuance remain there even when the new backend runs in an EU data center. Confirm this with your data residency owner before routing personal data through a split design.
Verifying Firebase tokens on the new backend
A self-hosted backend must decide whether to trust Firebase ID tokens or to issue its own. Trusting Firebase tokens means the backend verifies signatures against Google's published keys and maps the Firebase user ID to its own user table. Issuing its own tokens means users sign in twice during the transition, so plan the bridge and its expiry carefully.
Two sources of truth
While Firestore or Realtime Database holds one copy of a record and the new Postgres or Appwrite database holds another, the two can drift. Name one system as the owner of each record type and document which writes go to which store. For illustrative purposes, a chat message written to Realtime Database but shown from a Postgres replica will eventually disagree after a failed sync.
Dual-write and sync jobs
A temporary sync process copies changes between Firebase and the new backend. Decide whether writes go to both stores, whether one store is authoritative with a periodic copy, or whether a change feed drives the copy. Each choice affects latency, ordering and how you handle a failed write. Test replay and idempotency before any user traffic depends on it.
Security rules during coexistence
Firebase security rules and Postgres row level security enforce access in different places, so a record can be protected in one system and open in the other. Keep the rules for each record type in one reviewed source and test that a user cannot read through the new realtime channel what Firebase would deny. Confirm the exact rule semantics with each vendor's documentation.
Exit criteria for each phase
Define when the Firebase side is switched off for each feature, such as sign-in, presence or notifications. Write the criteria as checks: sync lag under an agreed threshold, reconciliation reports with zero unexplained differences, and a rollback path tested in staging. Without these gates, temporary bridges tend to become permanent.
Migrating Realtime Database data and listeners in phases
This sequence moves Realtime Database data and its listeners onto a Postgres or PocketBase data model in controlled stages, so each change can be tested and rolled back before clients depend on the new path.
Export the Realtime Database as JSON backups
Your Firebase project owner or an engineer with read access to the Realtime Database exports each path to JSON and stores the files in a restricted location within your own infrastructure. Realtime Database is not covered by Appwrite's built-in Firebase migration, and Supabase's documented scripts cover Firestore, Auth and Storage rather than the Realtime Database, so this export and every later load are manual or scripted work your team owns. The step is done when every top-level path has a JSON file, the file counts and key counts match what the Firebase console shows, and a checksum for each file is recorded.
Design the target schema from access patterns
Take the JSON tree and list the reads and writes each client screen performs, then map nested objects to tables with foreign keys, or to documents in Appwrite's databases if you choose that model. Decide which fields need row-level access rules, since Postgres row level security or Appwrite permissions replace Firebase security rules. The output is a reviewed schema document with one table or collection per entity, an index plan for the queries that the Realtime listeners depend on, and a list of fields that were denormalized in the Firebase tree and must be recombined.
Load the data into a staging environment
Engineers write a transformation script that reads the JSON exports and inserts rows into a staging Supabase or Appwrite instance, running in your own infrastructure. Keep the script idempotent so it can be rerun after schema changes. Load one path at a time, starting with the smallest, and compare row counts and sample records against the source. The step is complete when a full load runs without errors on staging and a reconciliation report shows matching counts and spot-checked values for each entity.
Rebuild listeners as realtime subscriptions
Replace each Firebase value listener with a subscription on the target platform, such as Supabase Realtime over Postgres changes, Appwrite Realtime channels, or PocketBase realtime subscriptions. Mapping is not one to one: Firebase listeners fire on the whole subtree, while the target models usually publish row or document events, so client code must merge events into local state. Confirm the event payloads, filtering and authorization behavior in the current documentation of the platform version you deploy. The output is a tested client module that reproduces each screen's live updates against staging data.
Test concurrency and reconnection behavior
Run load tests that open many persistent connections, simulate dropped networks, and force reconnects while writes continue, then verify that clients resynchronize without duplicate or missing updates. Measure connection counts and resource use on the self-hosted host, and confirm capacity against the vendor guidance for your chosen platform rather than assumptions. PocketBase scales vertically on one server, so its test should include a target connection count on the hardware you plan to run. The step is done when the test report shows no lost updates after reconnect and the resource limits you need are documented.
Run dual writes during a controlled overlap
If users cannot tolerate a pause, write changes to both Firebase and the new backend for a defined overlap period, with the Firebase write remaining the source of truth. Log every dual write, and run a daily reconciliation that compares records across both stores and reports mismatches. Dual writes add client or server complexity and recurring operating effort, so keep the overlap as short as your reconciliation results allow. The step is complete when the reconciliation shows no unexplained differences for the agreed window.
Cut over clients and retire Firebase writes
Release the client build that reads and writes the new backend, switch the server-side write path, and place Firebase Realtime Database into read-only mode once the old client population has fallen off. Keep the final JSON export and the reconciliation logs for audit and rollback reference. Confirm with your security and compliance owners that retained exports are stored under the same controls as production data. The step is done when production traffic reaches only the new backend, the final export is archived, and the rollback procedure has been rehearsed.
What does replacing Realtime Database cost and take?
What drives the effort of replacing Firebase Realtime Database?
The biggest drivers are the shape of your data, how many listeners the app keeps open, and how much offline behavior the app depends on. A flat or lightly nested JSON tree maps to Postgres tables or Appwrite collections with modest work, while deeply nested trees need a deliberate redesign into normalized rows. Listener count matters because each live subscription must be re-expressed as a Supabase Realtime subscription, an Appwrite Realtime channel or a PocketBase subscription, and each one needs its authorization rebuilt. Offline sync is the item most often underestimated, since Realtime Database's local cache behavior does not carry over automatically. Rewriting security rules into row level security or collection permissions is usually a separate, testable workstream.
Which costs are one-time and which recur after cutover?
One-time costs cover the data model redesign, client and listener rewrites, rule rewrites, data migration, load testing and cutover planning. Recurring costs cover the servers or virtual machines, storage, off-server backups, patching and upgrades, monitoring, and on-call coverage for incidents. Self-hosting moves the bill from usage metering to infrastructure and people. Ask any partner to separate these two categories in a quote so you can compare the recurring line with your current Realtime Database spend. Also ask who is paid for each item: the platform itself is free under its license, so the paid work is engineering, operations and support.
Can our team replace Realtime Database without outside help?
A team with strong backend and SQL skills can often do it in-house, particularly for a small app with a simple data model. The work is still cross-disciplinary: it covers schema design, realtime client code, authorization policies, Docker or Kubernetes operations, backups and restore tests. Check whether your team already operates Postgres or container platforms, has an on-call rotation, and can staff upgrades within a few days of each release. Supabase's self-hosting docs describe the self-hosted product as community-supported, so vendor support contracts are not included in a free install. Outside help is usually most valuable for the data model review, the load test and the cutover runbook.
What should we ask a partner to include in a quote?
Ask for a written scope that lists each listener type, each collection or table the app reads in realtime, and every rule that must be rebuilt. Request the deliverables in writing: data model, migration scripts, test plan, load test results, backup and restore procedure, runbook and handover documentation. Ask how offline behavior will be handled and what happens if the chosen connection count is not reached in testing. Clarify the timeline, the acceptance criteria and what is excluded, such as application feature work. DeployOpen works from a fixed scope agreed in writing before work starts, and ongoing support and upgrades are available as a retainer, so ask for those lines separately.
Do connection limits disappear when we self-host?
No. Self-hosting removes the Firebase connection quota, but it does not remove the limits of the hardware you choose. Scaling depends on the server, the database, the realtime service and the network path. PocketBase's FAQ says it scales only vertically on a single server and reports 10,000+ persistent realtime connections on a $4 Hetzner CAX11 VPS, which is the vendor's own figure and should be reproduced in your environment. Supabase self-hosting and Appwrite run multiple services, so their practical ceiling depends on how Realtime, the database and the gateway are sized. Load-test the exact configuration with your message rate and connection pattern before committing to a capacity plan.
How does the release cadence affect ongoing upkeep?
The platforms release often, so upkeep is a standing task rather than a one-off project. Appwrite 2.5.0 was released on October 13, 2026, and its installation guide uses the appwrite/appwrite:2.5.0 image. The self-hosted Supabase Docker configuration reached 0.8.3 on October 16, 2026, and its changelog flags security fixes for Storage and Realtime and one-way Storage migrations that require a database backup first. PocketBase v0.40.5 shipped on October 8, 2026, and its documentation warns that upgrades may need manual migration steps. Budget a recurring patch window, test each release in staging, and confirm your own upgrade policy with the vendor and your security team.
Who is responsible for backups and on-call after cutover?
Your organization is responsible for both once the platform runs in your infrastructure. Supabase's self-hosting docs list managed backups and point-in-time recovery as unavailable when self-hosting, so you need your own backup tooling, retention policy and tested restore procedure. PocketBase offers dashboard backups stored locally or in S3-compatible storage, and its production guide warns that performance can degrade slightly during backups. Appwrite's Helm chart docs say built-in datastores run a single replica without failover, so production data should use managed services or operators. Confirm recovery time and recovery point targets with the business owner, then decide who receives alerts and who is on call.
What the team must operate after cutover
The operating burden after cutover depends on which platform the team picks, and it is larger than the Firebase bill it replaces suggests. Supabase self-hosting is documented as a Docker Compose deployment of several services, including Postgres, Auth, PostgREST, Realtime, Storage and the Supavisor connection pooler, and each Docker configuration release pins specific upstream versions that the operator pulls and recreates. Appwrite offers Docker Compose and an official Helm chart, but its chart runs PostgreSQL, Redis, ClickHouse and object storage as single replicas without replication or failover. Production data on Appwrite therefore needs managed services or operators, which are a separate line item to price and staff. Ask whether the Realtime workload will run on Kubernetes or a single host, because that decision sets who patches the cluster.
PocketBase is simpler to run, with no external dependencies, but it scales only vertically on one server and has no official Docker image. The production guide recommends a systemd service, so the team must own the unit file, restart policy, log rotation and host updates. Backups are the other recurring task. PocketBase offers dashboard backups stored locally or in S3-compatible storage and warns that performance can degrade slightly while a backup runs, so schedule them for quiet hours and test restores. On Supabase, managed backups and point-in-time recovery are not available when self-hosting, so the team must design, run and verify its own Postgres backup and restore process before go-live.
Before launch, load test persistent connections with the traffic pattern of the real app, including reconnect storms after a network drop and a rolling restart of the realtime service. Measure connection counts, memory per connection, message latency and how quickly clients resubscribe. Confirm the vendor's current connection guidance for your chosen platform, since the figures published for PocketBase, such as its FAQ's 10,000+ persistent connections on a small VPS, describe a specific setup rather than your workload. Also confirm who answers a production incident: self-hosted Supabase is community-supported, and PocketBase is maintained on a volunteer basis, so the team should decide whether it needs a paid support contract or internal on-call coverage.
How DeployOpen scopes and delivers a realtime replacement
The sequence turns a Firebase Realtime Database dependency into a written scope, a tested realtime design running in your own infrastructure, and handover documentation your team can operate without us.
Agree the written scope
DeployOpen and your team agree in writing which apps, collections and listeners move, which target platform is in scope (Supabase Realtime, Appwrite Realtime or PocketBase subscriptions), where it will be hosted, and what is excluded. Engagements are fixed-scope, so deliverables and timelines are fixed in this document before any work starts. The step is done when both parties have signed off the scope and the exclusions list, including any hosted-only features you expect to lose.
Inventory schema and listeners
We catalog every Realtime Database path, the client listeners attached to each path, the write patterns that drive them, and the security rules that govern reads and writes. Your engineers confirm which paths are user-facing and which are internal. The output is a listener inventory and a draft mapping from the JSON tree to relational tables or documents, with the nested and denormalized data flagged for redesign. The step closes when your team has reviewed the mapping and the open questions are logged.
Design the data model and access rules
We translate the inventory into a target schema, choosing between Postgres tables with row level security on Supabase, collections and permissions on Appwrite, or SQLite collections with API rules on PocketBase. Channel or subscription boundaries are defined so each client only receives the rows it is allowed to see. We test these rules with negative cases, such as a user reading another user's path. The step is complete when the access tests pass and your security team has signed off the rule set.
Build and deploy in your infrastructure
We deploy the chosen platform into your cloud account, data center or air-gapped network using the vendor's supported installation path, then wire the client SDK changes and the write path that keeps any legacy clients in step during cutover. Secrets are generated during install rather than taken from example files, and Studio or admin consoles are restricted. The step produces a running environment, a configuration record and a change log that your team can audit.
Test load and failover
We run load tests that open persistent connections at your expected peak and measure message latency, dropped subscriptions and reconnect behavior under pressure. For Appwrite and Supabase, we also test failover of the database and the realtime service, because some self-hosted datastores run without replication by default and must be backed by managed services or operators. For PocketBase, we test the single-server ceiling against your real workload. The step closes with a written test report listing limits, failure modes and the measured thresholds, which drive the scaling decision.
Cut over and verify data
We migrate data with the platform's documented tooling where it applies, reconcile record counts and sample values between the old and new stores, then switch clients in a controlled window agreed in the scope. Realtime listeners are rechecked against live traffic, and a rollback path is rehearsed before cutover. The step is done when reconciliation reports match and your team confirms that listeners deliver updates from the new backend.
Document and hand over
We deliver architecture notes, the listener inventory, the access rule set, runbooks for restart, backup and restore, the load test report and a list of known gaps against the Firebase behavior. Operators are trained on monitoring connection counts and on upgrade steps for the platform release line you run. The handover is complete when your team has run the runbooks itself under our observation and the documentation is accepted.
Arrange retainers for upgrades
Because open-source realtime services release often, we offer retainers for ongoing upgrades, patching, continuous testing and support, priced from the written scope rather than from a published list. You can also run the platform alone with your own staff, using the documentation we deliver. Ask for the retainer terms in writing, including what is covered for security fixes and how upgrades are tested before they reach production.
