By ByteBot
Linear loads most pages in under 50 milliseconds. That number isn’t a marketing claim — it’s the outcome of an architectural decision made in the very first lines of code the founders wrote. A technical breakdown published this week reached 332 points on Hacker News and sparked a real debate: is Linear’s local-first approach what all web apps should be doing, or an over-engineered solution most teams can’t afford? The architecture is worth understanding either way.
The core inversion: in a standard web app, the server is the source of truth and the browser is a display layer. In Linear, those roles are reversed. The browser’s IndexedDB database holds the workspace data. The server is where data syncs. When you open Linear, the app hydrates from local storage into memory — no server query needed. That’s why there’s no “loading issues…” spinner. The issues are already on your machine.
Three Patterns That Eliminate Spinners
Linear’s speed comes from three interlocking decisions that work as a system. Remove any one and the performance degrades noticeably.
The first is local data availability. On boot, Linear reads from IndexedDB into an in-memory MobX object pool. Every UI query hits that local pool, not a server. Linear co-founder Tuomas made the trade-off explicit: “Literally the first lines of code that I wrote was the sync engine, which is very uncommon to what you usually do when you’re a startup.” Most startups defer architectural work until they have something working. Linear bet the opposite — the sync engine had to come first or nothing else would feel right.
The second pattern is optimistic mutations. When a user changes an issue title, Linear doesn’t wait for server confirmation:
// Standard web app: UI waits for server
const result = await api.updateIssue(id, { title: "New title" });
setIssue(result.data); // spinner visible until this line
// Linear's approach: UI updates instantly
issue.title = "New title";
issue.save(); // queues to IndexedDB, then syncs to server in backgroundThe mutation applies locally, gets written to a durable IndexedDB transaction queue, and then syncs to the server asynchronously. The network is completely hidden from the user’s experience — exactly as Linear describes it: “The secret to building incredible web apps is by hiding all the network requests from the user.”
The third pattern is granular MobX observables. Every property on every model is its own observable. Components wrapped in observer() re-render only when their specific fields change. A 50-issue bulk update triggers 50 targeted cell re-renders — not a full list re-render. This is the mechanism that makes collaborative editing feel smooth even with teammates actively making changes. A reverse-engineering of Linear’s sync engine, endorsed by their CTO, confirmed that conflict resolution uses monotonically increasing sync IDs rather than CRDTs — the server establishes total ordering of all transactions.
The Trade-offs They Don’t Put in the Press Release
Local-first is not a free lunch. The performance gains are real, but so is the complexity. Schema migrations have to run on every client device — you can’t just run a database migration and move on. Safari historically clears IndexedDB after 7 days of non-use, which means the server backup role is actually critical for data durability, not optional. Debugging sync bugs is genuinely hard: race conditions between local and server state are notoriously difficult to reproduce.
Security is another dimension most tutorials skip. Data partitioning has to be correct — each user must only sync records they’re authorized to see. Linear’s PostgreSQL issues table is partitioned 300 ways, which hints at how seriously they take this. The architecture isn’t complex because Linear over-engineered it; it’s complex because the problem is complex.
The benchmark contrast is worth stating plainly: according to independent testing in 2026, Linear API queries average around 47 milliseconds. Identical Jira operations average around 3,200 milliseconds. That’s not a configuration difference. It’s an architecture difference.
2026: The Local-First Ecosystem Is Catching Up
Until recently, the local-first pattern was mostly aspirational outside of companies with Linear-level engineering resources. That’s changing. Local-First Conf 2026 held its third annual event this year. Sync-as-a-service platforms like ElectricSQL and PowerSync are abstracting the hardest parts of the pattern — teams can get local-first performance without writing their own sync protocol from scratch.
The adoption data is worth tracking. Jira’s new customer signups dropped 32% year-over-year from 2025 to 2026, while Linear closed the new-customer acquisition gap from a 3:1 Jira advantage in early 2025 to near parity in 2026. Developers are voting with their teams. Moreover, the foundational thinking behind local-first is well-documented in Ink & Switch’s local-first manifesto — essential reading if this architecture pattern is new territory.
That said, the right conclusion isn’t “everyone should rebuild their app this way.” It’s more specific: if your app is interaction-heavy and perceived speed is a competitive differentiator, local-first is no longer an exotic bet. The tooling exists. However, if you’re building a content-heavy site, a simple CRUD app, or anything where SEO matters significantly, the complexity won’t pay off.
Key Takeaways
- Linear’s sub-50ms loads come from treating the browser’s IndexedDB as the primary data store and the server as a sync target — the co-founder wrote the sync engine before any product features
- Three patterns work as a system: local data hydration on boot, optimistic mutations (UI updates before server confirmation), and granular MobX observables that trigger surgical re-renders
- The trade-offs are real: schema migrations run on every client, Safari clears IndexedDB after 7 days, and debugging sync bugs is notoriously difficult — this pattern isn’t right for most apps
- The ecosystem is maturing: sync-as-a-service platforms like ElectricSQL and PowerSync are making local-first tractable without writing your own protocol from scratch
- Jira’s -32% YoY signup drop and Linear’s near-parity in new customer acquisition suggest developers choose their tools based on whether the architecture hides or creates latency
