How Motion Built Their Sync Engine on Kurrent

Motion is an AI-first workplace suite with 30 products spanning calendar, email, tasks, CRM, project management, and docs. When they needed real-time sync across all of them, they chose KurrentDB as the foundation.

THE CHALLENGE

30 products. Everything needs to be fast.

Motion's users expect Linear-level and Superhuman-level responsiveness across every product in the suite. As the platform grew from a few tools to 30 interconnected products, the traditional database-backed architecture started showing cracks.

• Every product needs real-time, bi-directional sync between clients and server
• Users expect instant UI updates — no loading spinners, no stale data
• Schema changes across 30 products need to happen without downtime
• The engineering team is growing and needs predictable patterns

WHAT THEY TRIED

Why not Redis? Why not Kafka?

Before choosing Kurrent, Motion evaluated the tools most teams reach for when building sync infrastructure. Both fell short.

Redis
Redis is a key-value store — great for caching, but it doesn't help with the stream management decisions that define a sync engine. How do you organize streams? Per-user? Per-workspace? Per-entity? Redis doesn't have opinions about this, and building those abstractions from scratch meant reinventing a database.

Kafka
Kafka is powerful but opinionated. It requires knowing your topology in advance — how many partitions, which topics, what consumer groups. For a team building a product that's evolving rapidly, this rigidity is a deal-breaker.

WHY KURRENT

The flexibility advantage.

What sold Motion on Kurrent wasn't a feature comparison chart — it was the realization that KurrentDB turns one-way door decisions into two-way doors. They could start with one stream topology and change it later without downtime.

"We saw the flexibility of Kurrent in action. Without any downtime, we were able to go from one system to immediately say, no problem — we now have a stream per workspace." - Chander Ramesh, CTO

This flexibility proved transformative. Motion started with a simple stream-per-service model, then evolved to stream-per-workspace, then per-user within workspaces — all without migrations, downtime, or data loss.

• Spin up new streams for new products instantly
• Merge streams, split streams, create projections across streams
• Change topology decisions at runtime — not at deploy time
• No schema migrations, no downtime windows, no data backfills

"All of these crazy one-way door decisions instantly become two-way door decisions." - Chander Ramesh, CTO

THE ARCHITECTURE

How Motion uses Kurrent today.

For products on the sync engine, KurrentDB serves as the primary data store. Events flow from the client through Kurrent streams and back, with IndexedDB on the client holding local state for instant reads.

• Kurrent is the primary data store for all sync-enabled products (calendars, emails, tasks)
• IndexedDB on the client provides instant reads from local state
• Background sync keeps clients and server in sync via Kurrent streams
• All writes go through events — no direct database mutations
• Goal: all 30 products running on Kurrent by end of 2026

"For services on the sync engine, Kurrent is the primary data store. We couldn't do that without Kurrent." - Chander Ramesh, CTO