Linear's Speed: Browser DB and Sync Engine Are Key

Any developer who has used the project management tool “Linear” will have noticed that its UI is significantly faster than traditional CRUD applications. While updating a single issue takes just a few milliseconds, typical apps require around 300 milliseconds. Where does this difference come from? An article detailing Linear’s internal implementation has been published and is generating discussion.

The article was written by Dennis Brotzky. While he clarifies that he is not a Linear employee and has not directly seen the codebase, he analyzes the performance secrets based on public information and actual user experience. In short, there is no single silver-bullet technique; rather, it is the result of countless small decisions built on a solid foundation.

Using the Browser as a Database

Linear’s most critical design decision is that the database the UI reads from is located inside the browser, specifically in IndexedDB. Traditional web apps send an HTTP request to the server for every user action, wait for the server to query the database, and then update the UI. During this time, a spinner, skeleton screen, or frozen UI lasts for hundreds of milliseconds.

Linear reverses this relationship. Changes are first applied locally, then pushed asynchronously to the server. The server broadcasts the diffs to other clients via WebSocket.

Brotzky points out that “the biggest barrier to building a fast web app is the network.” Data transfer between client and server always takes hundreds of milliseconds. Therefore, the best approach is to eliminate network requests altogether, and Linear does exactly that.

The difference is clear in code examples. In a traditional app, updating an issue requires sending a fetch PATCH request and waiting for the response before updating the UI. In Linear, it’s done with two lines: issue.title = "Faster app launch"; issue.save();. The first line immediately updates the data store in memory (in Linear’s case, a MobX observable), and the second line queues the transaction in the sync engine. The UI is immediately re-rendered without waiting for background synchronization.

Making the First Load Instant

Linear’s fast initial load is also notable. Rather than just showing a splash screen, it includes numerous optimizations to make the app immediately usable.

A specific technique is pre-caching the necessary data. When a user opens the app, data from the previous session stored in IndexedDB becomes instantly available. With this data, the app can restore the last working state without waiting for a server response. It then synchronizes diffs with the server in the background to update to the latest state.

This approach is close to the “offline-first” design philosophy. However, Linear does not claim to be fully offline-capable; its focus is solely on providing an experience that makes the network invisible.

Sync Engine Design

The sync engine at Linear’s core maintains data consistency across multiple clients. Local changes are batched and periodically flushed to the server. The server handles conflict resolution and validation, then propagates changes to other clients.

The advantage of this design is that communication with the server does not occur on every edit operation. Frequent network requests during typing or drag-and-drop operations would severely degrade UI responsiveness. Linear avoids this by queuing changes and sending them in batches at appropriate times.

Brotzky repeatedly emphasizes that “the secret to building a great web app is to hide all network requests from the user.” Reducing loading states greatly influences the user’s perception of performance.

Design Decisions Optimized for Speed

Linear’s performance stems not only from architectural decisions but also from meticulous optimizations in every detail. For example, in component rendering optimization, only the parts that changed are redrawn. The reactive data flow using MobX observables minimizes unnecessary re-renders.

Animation handling also has its own characteristics. Animations are not mere visual decoration; they aim to psychologically shorten the perceived time lag between user actions and feedback. By applying the right animation at the right time, reactions to operations feel faster than the actual processing time.

Editorial Opinion

Short-term Impact: Linear’s design approach offers insights applicable not only to project management tools but to all CRUD applications. Especially in markets where SaaS product UI/UX quality is a differentiator, we expect to see an increase in competing products adopting similar approaches within the next six months. The architecture combining IndexedDB with background synchronization has high compatibility with modern frontend frameworks like React and Vue, making the barrier to adoption relatively low.

Long-term Perspective: Over a 1–3 year span, the design philosophy of “using the browser as the primary database” has the potential to fundamentally transform web application architecture. In the traditional client-server model, the network was always the bottleneck. If this is resolved, web app responsiveness could rival that of native apps, and even offline operation could become standard. However, data consistency and conflict resolution complexity remain challenges, requiring caution when applying to large-scale collaboration applications.

Question from the Editorial Team: What is interesting about this analysis is that exactly how strictly Linear handles conflict resolution is not fully visible from the outside. In a local-first architecture, conflicts when multiple users simultaneously edit the same data are inevitable. How does Linear handle this? Additionally, to what extent do IndexedDB storage limits and browser implementation differences pose constraints in real-world use? Clarifying these questions would provide more products with the decision-making basis to adopt a similar architecture.

References

• How’s Linear so fast? A technical breakdown - performance.dev — Published May 3, 2026