--- title: "Solving HTAP for a Trillion-Table System" url: https://daily.dev/posts/solving-htap-for-a-trillion-table-system-2dbsio2em source_url: https://engineering.monday.com/mondaydb-3-solving-htap-for-a-trillion-table-system type: article source: "monday Engineering" published: 2026-05-19T09:15:57.922Z updated: 2026-05-19T09:16:29.307Z tags: ["duckdb"] reading_time: 22 upvotes: 5 comments: 3 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Solving HTAP for a Trillion-Table System **[monday Engineering](https://daily.dev/sources/monday)** · 22 min read · 5 upvotes · 3 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community discussion Top comments from developers on daily.dev. **@ryansgi** · 1 upvotes > Very cool. I've been hearing about DuckDB for a while but I always kinda dismissed it as a gimmick without doing any research, my bad. > > One thing I'm curious about is the "external WAL" - I wonder what that looks like? **@bjro** · 0 upvotes > Good read. What makes this work is that most queries are board-local and read-heavy, and they knew that going in. If your workload doesn't look like that, copying the architecture probably won't carry the wins over. Still interesting for how they thought about the partition boundary. **@al\_v\_a\_ro** · 0 upvotes > Very interesting. A big pile of smart decisions. --- Tags: [#duckdb](https://daily.dev/tags/duckdb) [View this post on daily.dev](https://daily.dev/posts/solving-htap-for-a-trillion-table-system-2dbsio2em)