//! This page documents some limitations that sled imposes on users.
//!
//! * The underlying pagecache can currently store 2^36 pages. Leaf nodes in the
//! `Tree` tend to split when they have more than 16 keys and values. This
//! means that sled can hold a little less than **4,294,967,296 total items**
//! (index nodes in the tree will also consume pages, but ideally far fewer
//! than 1%). This is easy to increase without requiring migration, as it is
//! entirely a runtime concern, but nobody has expressed any interest in this
//! being larger yet. Note to future folks who need to increase this: increase
//! the width of the Node1 type in the pagetable module, and correspondingly
//! increase the number of bits that are used to index into it. It's just a
//! simple wait-free grow-only 2-level pagetable.
//! * keys and values use `usize` for the length fields due to the way that Rust
//! uses `usize` for slice lengths, and will be limited to the target
//! platform's pointer width. On 64-bit machines, this will be 64 bits. On
//! 32-bit machines, it will be limited to `u32::max_value()`.
//! * Due to the 32-bit limitation on slice sizes on 32-bit architectures, we
//! currently do not support systems large enough for the snapshot file to
//! reach over 4gb. The snapshot file tends to be a small fraction of the
//! total db size, and it's likely we'll be able to implement a streaming
//! deserializer if this ever becomes an issue, but it seems unclear if anyone
//! will encounter this limitation.