Lovable Realtime centralizes Firestore and Spanner permissions

By Marcus Bennett

Lovable reported on November 9, 2026 that Lovable Realtime reached 2.06 million peak concurrent subscriptions during a 30-day measurement period, after the company completed the migration of its frontend off Firestore.

The custom service centralizes authorization in Lovable's Go backend. That backend now determines which records a user can access and which fields remain visible, while a single subscription can combine Firestore and Spanner data and refresh when either source data or permissions change.

For Lovable's AI app-building platform, the redesign addresses two concrete risks: browser-side rules could expose fields through routine document changes, and duplicate live-data streams consumed capacity shared with ordinary database requests.

Why did Lovable replace browser-side Firestore listeners?

Lovable said parts of its platform previously used browser-based Firestore onSnapshot listeners, which delivered live document updates. The browser received entire documents, while Firestore rules had to mirror the permission model in Lovable's Go API.

According to Lovable, that architecture tied exposure to routine document changes. A developer adding a field could determine what reached users' browsers without necessarily recognizing the visibility consequence.

Firestore rules can query Firebase data but not Spanner, Lovable reported. The limitation complicated authorization for large enterprise groups synchronized through SCIM, a protocol that syncs users and groups into a Lovable workspace.

Lovable's temporary proxy through the Go API served business and enterprise customers by reusing the API's permission checks. It also opened separate upstream Firestore listeners for each client's dependencies, duplicating streams and consuming capacity in a connection pool shared with ordinary database requests.

Lovable required its replacement to meet three core conditions:

• Work with both existing databases, Firestore and Spanner.
• Re-evaluate access continuously and close a revoked user's stream during an active session.
• Withhold unauthorized fields before any data left the server.

Lovable said it evaluated transport, synchronization, and database-integrated options. It found none that supplied the required combination without substantial integration work, a database change, or replication into Postgres.

How does Lovable Realtime enforce access and deliver live updates?\n

Lovable's Go service runs on GKE, the container environment where the company hosts the service. It opens one WebSocket, a persistent browser connection, per tab and multiplexes multiple subscriptions over that connection.

In Lovable's design, change-data-capture (CDC), which carries database changes, moves Firestore and Spanner updates through a bridge to NATS, the service's message bus. Matching subscriptions then recompute their views, compare xxh3-128 hash values, and send deltas, or partial updates, only when the output changes.

Lovable says one subscription can draw from both databases while applying the API's permissions framework. The company treats authorization as another reactive data source, allowing permission changes to trigger fresh results independently of ordinary document edits.

Lovable reported that recomputing only when fields involved in access decisions changed, rather than on every relevant document update, reduced permission recomputes by about 84%.

The service has approximately 40 subscription types owned by seven teams. Lovable said those types use typed interfaces, shared server-side subscriptions, and alerts routed to the team responsible for each subscription.

How did Lovable validate the rollout?

Lovable first ran Lovable Realtime in shadow mode. The frontend exercised the complete new path but discarded its payloads, continuing to render data from Firestore while the company tested against actual traffic and data shapes.

Lovable said that testing exposed reconnect storms after deployments, misclassified errors, and a payload cap that proved too small for real data. The company then used a feature flag to raise availability from 1% to 10%, 50%, and 100% of users over several days.

Lovable said the staged rollout produced “no user-facing incident” and no regression in its monitored metrics. The staged production rollout therefore became the primary validation for the new permission and synchronization path.

Why did the service need connection-aware scaling?\n

WebSocket connections are sticky and can remain active for hours, Lovable explained. Adding pods, or additional computing instances, therefore does not by itself shift existing load onto the new instances.

Lovable balances on connection count and scales using connections alongside CPU and memory usage. The company also caps connections per pod to limit the size of reconnection waves after an outage or deployment.

Under Lovable's design, reconnecting clients send a fingerprint of their cached state. The server rechecks authorization and confirms that the data remains unchanged, allowing Lovable to avoid transmitting it again.

How much of the implementation did coding agents handle?\n

The author of Lovable's post said the core took 40 hands-on working days. Coding agents handled most of the implementation after the team had worked through the architecture and edge cases.

Lovable's integration rig combined Firestore, Auth, and Spanner emulators with an embedded NATS server. It also used emulator-minted ID tokens, or test credentials generated by those emulators, allowing the coding agents to test changes across the full stack.

What did production traffic show?\n

From September 5 through October 5, 2026, Lovable reported three payload results:

• 2.61 billion data and patch frames crossed the service, excluding resumed control frames.
• Full snapshots for every computed result would have generated an estimated 40 TB of application payload.
• Deduplication, or the removal of repeated data, delta delivery, and reconnect reuse brought actual payload to 1.11 TB, an estimated 97% reduction from that baseline.

Lovable said these payload figures exclude protocol and transport overhead. The comparison therefore covers application data sent to clients, not every byte exchanged by the underlying infrastructure.

How quickly did updates become ready to send?\n

Lovable measured the interval between a source database write and an outgoing frame being ready for transmission at 66 milliseconds at p50 and 249 milliseconds at p99. Here, p50 denotes the median and p99 the 99th percentile.

The company excluded socket writes, network time, and client processing from those measurements. Lovable therefore described the figures as server-side readiness times, not complete user-perceived update latency.

What could Lovable Realtime become inside customer apps?\n

Lovable said it is “actively adding domain-event primitives” for cases where consumers need notice that something happened rather than a snapshot of current data. Those primitives would provide event notifications instead of computed data views.

The company said Lovable Realtime might later become a capability inside apps built with Lovable. Such an extension would give customer-created applications backend-controlled permissions and live views across Firestore and Spanner data.

Lovable's current deployment already serves as a shared foundation for richer collaboration as its data infrastructure evolves. The next product test is whether that internal foundation can become a reusable customer-facing capability while retaining backend-controlled permissions and live views.