Lovable builds Realtime service to replace direct Firestore listeners

Why Lovable moved away from Firestore listeners

Lovable says its earlier frontend architecture opened Firestore onSnapshot listeners directly from the browser. That meant the browser received entire Firestore documents, while Firestore rules had to mirror the permissions model in the company’s Go backend.

This created a risk whenever a database document gained a field, because adding that field could also expose it to the browser. Firestore Security Rules also could not read Spanner, which became a problem for permission updates involving large groups. Lovable’s SCIM feature synchronizes users and groups with workspaces, and the company says those operations require large database transactions and query patterns that document databases such as Firestore do not provide to the same level as Spanner.

Lovable temporarily proxied some subscriptions through its Go API for businesses and enterprises. However, the proxy opened separate Firestore listeners for each client’s data dependencies. At millions of live subscriptions, the company says that approach would require millions of long-lived upstream streams, often watching the same data repeatedly.

A backend-controlled realtime architecture

Lovable Realtime is designed to work with the company’s existing Firestore and Spanner data rather than requiring a move to another primary database. It continuously re-evaluates authorization while a connection remains open, allowing a revoked user’s stream to close mid-session. The backend also decides which fields appear in each payload, so fields a caller cannot access do not leave the server.

The service uses one WebSocket per browser tab, with subscriptions multiplexed over that connection. Change data capture sends updates from Firestore and Spanner through a bridge to NATS. When a message arrives, the service dispatches it to matching subscription instances, recomputes each data projection, deduplicates the result using an xxh3-128 hash, and sends a delta to the frontend when the output has changed.

The service runs in Go on GKE. According to Lovable, each pod holds one NATS connection and thousands of WebSocket connections. NATS provides hierarchical wildcard subjects and interest-based cluster routing, so messages are sent to nodes with matching subscribers rather than being broadcast across every node.

What the system means for developers and users

Lovable says developers use a backend framework and a frontend SDK. On the frontend, a developer supplies a subscription name and parameter. Parameters and payloads are typed end to end from Go structs, while multiple components subscribing to the same data can share one server-side subscription automatically. The SDK also manages reconnects with backoff and jitter, as well as authentication-token refresh frames.

On the backend, a subscription function resembles an endpoint: it receives parameters, checks access, reads the required data, and returns the response object. The framework tracks the data used by that function and calls it again when those dependencies change. Lovable says this also lets permission changes alter a subscription’s output, rather than limiting updates to direct database changes.

The core service was built in 40 hands-on working days and rolled out to every user without a user-facing incident, according to Lovable. The company’s stated goal is to keep realtime delivery connected to its existing databases while centralizing permission decisions and reducing the data exposed to browsers.