Vertical Scaling
Vertical scaling, or "scaling up," boils down to adding more resources to a single server to increase its capacity. This is often the simplest way to handle increased load, as it doesn’t require changes to the application’s architecture.
Scaling up can be achieved in several ways. The most direct method is upgrading the server’s hardware. In TypeDB Cloud this can be handled by migrating the cluster to a larger machine size.
Threading model
TypeDB’s query model is currently optimized for being efficient and lightweight. Each query runs single-threaded, so utilizing more CPU and memory resource is best achieved through many concurrent queries and transactions.
Planned work will enable concurrent execution within 1 query and provide major performance improvements when increasing machine size and executing individual queries.
Memory model
The primary consumers of memory in TypeDB are RocksDB’s caches and buffers, plus working memory buffers per transaction. Any writes submitted to a transaction are buffered in memory until commit, so keeping transactions relatively small (100-1000 queries) is optimal.
RocksDB memory is governed by two pools, each a single budget shared across all databases on the server (not allocated per database):
-
a block cache (the in-memory cache of data read from disk), which defaults to a soft limit of 1 GiB. It may grow beyond this when critical indices are pinned in memory.
-
a write-buffer budget (cached writes before they are flushed to disk), which defaults to 512 MiB.
Note that increasing or decreasing these does not affect the durability of commits - the write ahead log (WAL) separately records writes to disk regardless of TypeDB’s and RocksDB’s in-memory state.
Both pools are configurable via the server’s configuration — see Storage configuration and the memory-usage sizing guidance. On top of these, RocksDB also benefits from the operating system’s page cache, which is managed by the OS outside the TypeDB process.
To maintain performance we recommend that at least 5% of the total of all your databases' sizes fits in memory, to ensure indexes and bloom filters remain in memory.