# The RUM Conjecture: You Cannot Optimize Reads, Updates, and Memory at Once

DevFeed: [The RUM Conjecture: You Cannot Optimize Reads, Updates, and Memory at Once](<https://devfeed.tech/articles/the-rum-conjecture-you-cannot-optimize-reads-updates-and-memory-at-once-39565.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/13-rum-conjecture-database-tradeoffs/>)

Author: hello@ankit-rana.com

Published: 2026-03-17T00:00:00Z

Content type: article

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [systems](<https://devfeed.tech/topics/systems.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Apache Cassandra](<https://devfeed.tech/topics/cassandra.md>), [rocksdb](<https://devfeed.tech/topics/rocksdb.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>)

Tags: [b-tree](<https://devfeed.tech/tags/b-tree.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [cassandra](<https://devfeed.tech/tags/cassandra.md>), [database](<https://devfeed.tech/tags/database.md>), [databases](<https://devfeed.tech/tags/databases.md>), [dram](<https://devfeed.tech/tags/dram.md>), [indexing](<https://devfeed.tech/tags/indexing.md>), [latency](<https://devfeed.tech/tags/latency.md>), [memory](<https://devfeed.tech/tags/memory.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [node](<https://devfeed.tech/tags/node.md>), [performance](<https://devfeed.tech/tags/performance.md>), [rocksdb](<https://devfeed.tech/tags/rocksdb.md>), [storage-engine](<https://devfeed.tech/tags/storage-engine.md>), [system-design](<https://devfeed.tech/tags/system-design.md>)

## AI overview

The article explains the RUM Conjecture, which describes a tradeoff among read overhead, update overhead, and memory overhead in database indexes and storage engines. It compares B-Trees, LSM-Trees, and hash indexes to show how each optimizes different tradeoffs.

## Source excerpt

You can strictly optimise at most two of read overhead, update overhead, and memory overhead; the third will be expensive. B-Trees optimise reads and memory and pay on writes. LSM-Trees optimise writes and memory and pay on reads. Hash indexes optimise reads and writes and pay in RAM. The useful question is not whether a database is good but which corner it optimises and what you are willing to pay for the other two.