LiveGraph: real-time data fetching at Figma | Figma Blog (opens in new tab)

LiveGraph is Figma’s in-house real-time data-fetching layer built on PostgreSQL. It lets frontend developers declare live data views with GraphQL-like queries, while LiveGraph reads PostgreSQL’s replication stream to deliver updates within milliseconds. Figma built it to replace fragile, manually maintained client events and to support real-time subscriptions at large scale without relying on polling or a new database technology.

Problems with Figma’s Earlier Real-Time Architecture

• React clients initially loaded large data sets through Ruby HTTP endpoints and stored them in Redux.
• Backend code manually emitted events whenever database records changed.
• Frontends subscribed over WebSockets and applied those events to client state.
• As data volumes grew, Figma split requests into incremental loads, making data ownership and availability harder to reason about.
• Complex changes—such as permission updates affecting many resources—were difficult to represent with individual events.
• Events could arrive out of order or fail to correspond reliably with database writes, causing client state to diverge from server state.

Why Figma Chose Live Queries

• Figma wanted developers to define data subscriptions declaratively rather than manually coordinate fetches and update events.
• GraphQL provided a natural interface for describing the relevant portion of the object graph.
• LiveGraph uses “live queries,” which keep query results synchronized, rather than GraphQL subscriptions in the narrower sense of consuming event streams.
• The system is a query and data-fetching layer over existing PostgreSQL infrastructure, not a replacement persistence layer.

In-House System Versus Existing Tools

• Figma’s multiplayer service handles collaborative writes and conflict resolution within individual files, whereas LiveGraph focuses on reading application data.
• Systems such as Hasura, Prisma, and PostGraphile offered GraphQL subscription features but were not designed primarily for Figma’s scale of concurrent live subscriptions.
• Polling was rejected because it increases database load and requires developers to choose polling intervals for each query.
• Figma’s collaborative product made real-time data central enough to justify building and operating a specialized internal system.
• The company did not claim LiveGraph was universally superior; its value came from matching Figma’s specific scale and requirements.

Replication-Stream-Based Updates

• LiveGraph executes queries directly against PostgreSQL.
• It tails the database replication log to detect changes instead of repeatedly polling tables.
• Reading the replication stream enables update latency measured in milliseconds.
• Because the system must process the complete volume of database changes, its architecture needs to distribute updates across machines and database shards.
• This approach separates the complexity of detecting database changes from product code, allowing frontend engineers to work with declarative JSON data views.

Frontend API

• Product developers send GraphQL-like queries and receive results as JSON trees.
• A schema defines server-side entities and relationships, while views expose queryable subsets of that graph.
• The frontend can therefore request the data it needs and rely on LiveGraph to keep the result synchronized as the underlying PostgreSQL data changes.

LiveGraph’s central recommendation is architectural: derive live client views from the database’s authoritative change stream rather than maintaining a parallel network of hand-written events. For organizations with similar scale and real-time requirements, this can improve consistency and simplify product development, though Figma’s in-house approach was justified by its unusually collaborative workload.