Lovable Realtime trims payload to 1.11 TB, an estimated 97% cut

By Amara Osei

Lovable said Lovable Realtime reduced application payload by an estimated 97%, sending 1.11 TB versus a 40 TB full-snapshot baseline during September 5 through October 5, 2026. Lovable also reported 2.06 million peak concurrent subscriptions during a 30-day measurement in its November 9, 2026 post.

What changed when Lovable moved off Firestore?

Lovable reported on November 9, 2026, that its frontend had completed the full Lovable Realtime deployment and moved off Firestore. The custom Go service centralizes authorization and visible-field decisions across Lovable’s AI app-building platform, according to Lovable. It combines Firestore and Spanner data and refreshes a user’s view when either the information or that user’s permissions change, Lovable said.

Before the rollout, Lovable said parts of the frontend used browser-based Firestore onSnapshot listeners. The browser received entire documents, while Firestore rules had to mirror the Go API’s permission model, according to Lovable. Lovable said routine field additions could determine what reached users’ browsers without developers necessarily recognizing the exposure.

Why did enterprise permissions force a new backend?

Lovable said Firestore rules can query Firebase data but cannot query Spanner. The gap complicated authorization updates for large enterprise groups synchronized through SCIM, which syncs users and groups into a Lovable workspace, according to Lovable.

A temporary Go API proxy served business and enterprise customers and reused API permission checks, Lovable reported. It also opened separate upstream Firestore listeners for each client’s dependencies, duplicating streams and consuming capacity in a shared database-request connection pool, according to Lovable.

How does Realtime control data and access?

According to Lovable, the replacement had to work with both existing databases, continuously re-evaluate access and close a revoked user’s stream mid-session. It also had to withhold unauthorized fields before any data left the server.

Lovable assessed transport, synchronization and database-integrated options and found they lacked that combination without substantial integration work, a database change or replication into Postgres.

The resulting Go service runs on GKE and opens one WebSocket per browser tab, with subscriptions multiplexed over the connection, Lovable reported. Change-data-capture feeds carry Firestore and Spanner changes through a bridge to NATS, the service’s message bus, according to Lovable.

Matching subscriptions recompute their views, compare xxh3-128 hashes and send deltas only when output changes, Lovable said. A single subscription can draw from both databases while applying the Go API’s permissions framework, according to Lovable.

Lovable treats authorization as another reactive data source, allowing permission changes to trigger fresh results independently of ordinary document edits. Recomputing only when fields involved in access decisions changed, rather than on every relevant document update, reduced permission recomputes by about 84%, Lovable reported.

The service has approximately 40 subscription types owned by seven teams, Lovable said. It also provides typed interfaces, shared server-side subscriptions and team-routed alerts, according to Lovable.

How did shadow traffic validate the rollout?

Lovable said it first ran the service in shadow mode, with the frontend exercising the full new path, discarding payloads and continuing to render from Firestore. Actual traffic and data shapes exposed three issues, according to Lovable:

• Reconnect storms followed deployments.
• Errors were misclassified.
• The payload cap was too small for real data.

A feature flag increased availability from 1% to 10%, 50% and 100% of users over several days, Lovable said. The rollout produced no user-facing incident and no regression in its monitored metrics, according to Lovable.

Because WebSocket connections are sticky and can last for hours, adding pods does not by itself move existing load, Lovable explained. The service balances on connection count and scales using connections alongside CPU and memory, according to Lovable.

It caps connections per pod to limit reconnection waves, Lovable said. After reconnecting, clients send a fingerprint of cached state; the server rechecks authorization and confirms the data is unchanged rather than transmitting it again, according to Lovable.

How much engineering did the service require?

The author of Lovable’s post said the core took 40 hands-on working days. Coding agents handled most implementation after architecture and edge cases were worked through, according to the author.

An integration rig combined Firestore, Auth and Spanner emulators with an embedded NATS server and real emulator-minted ID tokens, Lovable said. The setup allowed agents to test changes across the full stack, according to Lovable.

What did production measurements show?

From September 5 through October 5, 2026, Lovable recorded 2.61 billion data and patch frames, excluding resumed control frames. Lovable estimated that full snapshots for every computed result would have generated 40 TB of application payload.

Deduplication, deltas and reconnect reuse brought actual payload to 1.11 TB, an estimated 97% reduction, Lovable reported. The payload figures exclude protocol and transport overhead, according to Lovable.

Lovable measured the interval from a source database write to an outgoing frame being ready to send at 66 milliseconds at p50 and 249 milliseconds at p99. The measurements exclude socket writes, network time and client processing, so they do not represent complete user-perceived update time, Lovable said.

Could Lovable Realtime become a customer-app capability?

Lovable said it is actively adding domain-event primitives for consumers needing notice of an event rather than a data snapshot. The service might later become a capability inside apps built with Lovable, according to Lovable.

Lovable said the current deployment already gives its teams a shared foundation for richer collaboration as data infrastructure evolves. If Realtime moves into customer-built apps, backend-controlled permissions and live views would become a customer-facing feature rather than remain inside Lovable’s own platform.