monday.com replaced its MySQL, Cassandra, and Redis fleet with a purpose-built columnar serving layer powered by DuckDB, achieving 5x faster board loads, 20x for large boards, 50x for aggregations, and 40-60% infrastructure cost reduction. The architecture (mondayDB 3) uses CQRS with a batch layer (DuckDB files in S3), an external distributed WAL, and a soft-stateful serving layer of Go processes on NVMe-backed Kubernetes nodes. Key design decisions include per-tenant file isolation (one DuckDB file per board), a sync-then-query read pattern, and a custom routing layer called Ranja using Weighted Rendezvous Hashing for cache affinity. The migration of 1M+ organizations from MySQL took 18 months with zero downtime, using dual-read validation and feature-flag-controlled incremental rollout. The same architecture is now being extended as an AI contextual layer for text search, semantic retrieval, and RAG.
Table of contents
TL;DRHow We Got HereWhat Matters First – ResultsmondayDB 3 – CQRS FTWThe WAL: Our External Write-Ahead LogRead Path: Sync-Then-QuerySmart Routing for Cache AffinityEntity Plugin SystemZero Downtime MigrationLessons LearnedWhy We Chose DuckDBWhat’s NextThank You.3 Comments
Sort: