Lovable Builds Realtime Service to Centralize Data Permissions

Lovable reported on November 9, 2026 that its frontend had moved off Firestore with the full deployment of Lovable Realtime, a custom service that centralizes authorization and reached 2.06 million peak concurrent subscriptions during a 30-day measurement period.

The migration places decisions about access and visible fields in Lovable’s Go backend. For the company’s AI app-building platform, the service provides one way to combine Firestore and Spanner data and update a user’s view when either the underlying information or that user’s permissions change.

Centralizing Permissions and Live Data

Parts of Lovable previously used browser-based Firestore onSnapshot listeners for updates. The browser received entire documents, while Firestore rules had to mirror the Go API’s permissions model. The design also made exposure part of routine document changes: someone adding a field could determine what reached users’ browsers without necessarily recognizing that consequence.

Firestore’s rules can query Firebase data but not Spanner, creating an obstacle for authorization updates affecting large enterprise groups synchronized through SCIM, which syncs users and groups to a Lovable workspace. A temporary proxy through the Go API for business and enterprise customers reused 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 the replacement to work with both existing databases, re-evaluate access continuously and close a revoked user’s stream mid-session. It also wanted unauthorized fields withheld before any data left the server. The company’s assessment was that the transport, synchronization and database-integrated options it evaluated did not provide 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 that connection. Change-data-capture feeds carry Firestore and Spanner changes through a bridge to NATS, the service’s message bus. Matching subscriptions recompute their views, compare xxh3-128 hashes and send deltas only when output changes. A single subscription can draw from both databases while applying the API’s permissions framework.

Authorization is treated 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, with typed interfaces, shared server-side subscriptions and team-routed alerts.

Shadow Traffic Validated the Rollout

Lovable first ran the service in shadow mode: the frontend exercised the full new path but discarded its payloads and continued rendering from Firestore. Using actual traffic and data shapes exposed reconnect storms after deployments, misclassified errors and a payload cap that was too small for real data. A feature flag then 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.

Because WebSocket connections are sticky and can last for hours, adding pods does not by itself move existing load. Lovable balances on connection count, scales using connections alongside CPU and memory, and caps connections per pod to limit reconnection waves. After reconnecting, clients send a fingerprint of their cached state, letting the server confirm that data is unchanged after rechecking authorization rather than transmit it again.

The post’s author said the core took 40 hands-on working days and that coding agents handled most implementation after the architecture and edge cases had been worked through. An integration rig combined Firestore, Auth and Spanner emulators with an embedded NATS server and real emulator-minted ID tokens, allowing the agents to test changes across the full stack.

Production Results and Potential App Support

For September 5 through October 5, 2026, Lovable reported 2.61 billion data and patch frames, excluding resumed control frames, and estimated that full snapshots for every computed result would have generated 40 TB of application payload. Deduplication, deltas and reconnect reuse brought actual payload sent to 1.11 TB, an estimated 97% reduction from that baseline. The payload figures exclude protocol and transport overhead.

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

Lovable said it is actively adding domain-event primitives for cases where consumers need notice that something happened instead of a data snapshot, and that the service might later become a capability inside apps built with Lovable. Such an extension would bring backend-controlled permissions and live views to customer-created applications. The current deployment already provides Lovable’s teams with a shared foundation for richer collaboration as their data infrastructure evolves.