The ART's Adaptive Fanout: 4, 16, 48 and 256

Jay Hubbert — Sun, 25 Oct 2026 15:40:00 +0000

TL;DR: DuckDB’s index is an Adaptive Radix Tree, and every part of the name is load-bearing. Radix: the tree branches on bytes, and shared leading bytes of the key are compressed into dedicated prefix nodes. Adaptive: each node grows through four layouts — Node4, Node16, Node48, Node256 — so a node with 3 children costs 40 bytes while a node with 200 children costs 2 KiB. Every node type gets its own FixedSizeAllocator, so a node is a fixed-size slot in a buffer-manager block. And every child reference is a single 64-bit word: buffer id | offset | node type, packed by hand because MSVC would have made it 16 bytes.

The index you actually use

 sql
 
 
CREATE TABLE t (id INTEGER, name VARCHAR);
CREATE INDEX idx ON t (name);
INSERT INTO t VALUES (1, 'alice'), (2, 'bob');

That CREATE INDEX builds an ART. So does a PRIMARY KEY on a table stored in DuckDB’s own format. When you then run a point lookup:

 sql
 
SELECT * FROM t WHERE name = 'alice';

the engine walks the ART comparing your key byte by byte against the key stored in the tree. The interesting question is: how is the tree laid out in memory, and what does the engine actually do for each byte of your key?

Three answers, in order of how much they matter:

Most of your key does not need to be compared at all — it is shared with other keys, so it is compressed into a prefix node.
The node you land in has a fanout that matches how many children it actually has.
Following a child is one 64-bit load and a couple of masks.

Radix over bytes

The ART is a radix tree over the bytes of the key. A naive trie would consume one byte per level: a 40-byte string key would need 40 levels, each with up to 256 children.

DuckDB avoids that with prefix nodes. When many keys share a leading run of bytes, that run is stored inline in a PREFIX node, together with a pointer to the child:

 cpp
 
 
// src/execution/index/art/prefix.cpp:42
Prefix Prefix::NewInternal(ART &art, NodePtr &node_ptr, const data_ptr_t data, const uint8_t count,
 const idx_t offset) {
	node_ptr = NodePtr::GetAllocator(art, PREFIX).New();
	node_ptr.SetMetadata(static_cast<uint8_t>(PREFIX));

	Prefix prefix(art, node_ptr, true);
	prefix.data[art.PrefixCount()] = count;
	if (data) {
		D_ASSERT(count);
		memcpy(prefix.data, data + offset, count);
	}
	prefix.child_slot->Clear();
	return prefix;
}

void Prefix::New(ART &art, reference<NodePtr> &node_ptr_ref, const ARTKey &key, const idx_t depth, idx_t count) {
	idx_t offset = 0;

	while (count) {
		auto min = MinValue(UnsafeNumericCast<idx_t>(art.PrefixCount()), count);
		auto this_count = UnsafeNumericCast<uint8_t>(min);
		auto prefix = NewInternal(art, node_ptr_ref, key.data, this_count, offset + depth);

		node_ptr_ref = *prefix.child_slot;
		offset += this_count;
		count -= this_count;
	}
}

Three things to notice.

The count byte lives at a fixed offset. prefix.data[art.PrefixCount()] = count; — the byte that says “how many bytes of key are in this node” is always at offset prefix_count, i.e. immediately after the key bytes. So the child pointer can be found with a single addition, and the prefix bytes can be memcmp’d in one go.

The prefix count is not a constant. It is computed from the key type, at load time:

 cpp
 
 
// src/execution/index/art/art.cpp:1225
void ART::SetPrefixCount(const IndexStorageInfo &info) {
	if (info.IsValid() && info.root_block_ptr.IsValid()) {
		prefix_count = Prefix::DEPRECATED_COUNT;
		return;
	}

	if (info.IsValid()) {
		auto serialized_count = info.allocator_infos[0].segment_size - Prefix::METADATA_SIZE;
		prefix_count = NumericCast<uint8_t>(serialized_count);
		return;
	}

	idx_t compound_size = 0;
	for (const auto &type : types) {
		compound_size += GetTypeIdSize(type);
	}

	// Get the maximum possible prefix size.
	// Minus one to index the prefix count (last byte).
	auto numeric_max = NumericLimits<uint8_t>().Maximum();
	uint8_t max_aligned = AlignValueFloor<uint8_t>(numeric_max - Prefix::METADATA_SIZE) - 1;

	// Ceiling of compound size,
	// minus one to index the prefix count (last byte).
	idx_t key_aligned = AlignValue(compound_size) - 1;

	// Set the prefix size to the maximum of the (compound) key size and the maximum prefix size.
	bool exceeds_max = key_aligned > NumericCast<idx_t>(max_aligned);
	prefix_count = exceeds_max ? max_aligned : NumericCast<uint8_t>(key_aligned);
}

For a BIGINT key, the compound size is 8 bytes, so prefix_count is 7 — and one prefix node holds the entire key. The tree for an integer index is one prefix node per distinct value plus a Node4 at the root. For a VARCHAR key, the compound size is the maximum string length, so prefix_count saturates at the maximum (254 minus the metadata size).

Long prefixes chain. Prefix::New loops, allocating a fresh prefix node for every prefix_count bytes. So a 1000-byte key becomes a chain of prefix nodes, each the same fixed size. The node size never depends on the key length — which is what makes it possible to allocate prefix nodes from a fixed-size allocator at all.

The fanout ladder

Radix tree nodes have to be able to hold up to 256 children, because a child is selected by a byte. But most nodes have a handful of children. A node that always reserved 256 child pointers would waste 2 KiB per node.

The ART’s answer is four layouts, and one function that picks between them:

 cpp
 
 
// src/execution/index/art/node.cpp:353
NType NodePtr::GetInternalNodeType(idx_t count) {
	if (count <= Node4::CAPACITY) {
		return NType::NODE_4;
	} else if (count <= Node16::CAPACITY) {
		return NType::NODE_16;
	} else if (count <= Node48::CAPACITY) {
		return NType::NODE_48;
	}
	return NType::NODE_256;
}

Node4 and Node16: a count, some bytes, some pointers

 cpp
 
 
// src/include/duckdb/execution/index/art/base_node.hpp:23
public:
	static constexpr NType TYPE = NODE_TYPE;

	BaseNode() = delete;
	BaseNode(const BaseNode &) = delete;
	BaseNode &operator=(const BaseNode &) = delete;

private:
	uint8_t count;
	uint8_t key[CAPACITY];
	NodePtr children[CAPACITY];

One template, two instantiations: Node4 : BaseNode<4, NType::NODE_4> and Node16 : BaseNode<16, NType::NODE_16>.

A Node4 is 1 byte of count + 4 key bytes + 4 × 8 bytes of child pointers = 37 bytes, padded to 40. Two of them fit in a 64-byte cache line, six fit in a 256-byte region. A Node16 is 1 + 16 + 128 = 145 bytes.

Lookup in both is a linear scan over the key bytes:

 cpp
 
 
// src/include/duckdb/execution/index/art/base_node.hpp:100
	static unsafe_optional_ptr<NodePtr> GetChild(BaseNode &n, const uint8_t byte, const bool unsafe = false) {
		for (uint8_t i = 0; i < n.count; i++) {
			if (n.key[i] == byte) {
				if (!unsafe && !n.children[i].HasMetadata()) {
					throw InternalException("empty child i = %d for byte %d in BaseNode::GetChild", i, byte);
				}
				return &n.children[i];
			}
		}
		return nullptr;
	}

For a Node4 that is at most 4 byte comparisons; for a Node16, at most 16. Both are branch-predictable in practice because the hot child in a radix tree is usually the same one.

Node48: the byte-indexed side table

Node48 is the interesting one. You could store 48 (key, pointer) pairs, but then a lookup is a linear scan over 48 entries, and each entry is 9 bytes, so the node is spread over 6 cache lines.

Instead, Node48 keeps a 256-byte index table keyed directly by the byte:

 cpp
 
 
// src/include/duckdb/execution/index/art/node48.hpp:20
class Node48 {
	friend class Node16;
	friend class Node256;

public:
	static constexpr NType NODE_48 = NType::NODE_48;
	static constexpr NType TYPE = NType::NODE_48;
	static constexpr uint8_t CAPACITY = 48;
	static constexpr uint8_t EMPTY_MARKER = 48;
	static constexpr uint8_t SHRINK_THRESHOLD = 12;

public:
	Node48() = delete;
	Node48(const Node48 &) = delete;
	Node48 &operator=(const Node48 &) = delete;

private:
	uint8_t count;
	uint8_t child_index[Node256::CAPACITY];
	NodePtr children[CAPACITY];

child_index[256] holds, for each possible byte, the slot number in the dense children[48] array — or EMPTY_MARKER (48) if there is no child for that byte. Lookup is therefore two array reads:

 cpp
 
 
// src/include/duckdb/execution/index/art/node48.hpp:114
	template <class NODE>
	static unsafe_optional_ptr<NodePtr> GetChild(NODE &n, const uint8_t byte, const bool unsafe = false) {
		if (n.child_index[byte] != Node48::EMPTY_MARKER) {
			if (!unsafe && !n.children[n.child_index[byte]].HasMetadata()) {
				throw InternalException("empty child for byte %d in Node48::GetChild", byte);
			}
			return &n.children[n.child_index[byte]];
		}
		return nullptr;
	}

n.child_index[byte] → slot → n.children[slot]. O(1), no branch on the search, no linear scan.

The cost is 256 bytes of index table (4 cache lines) that is mostly zeros for a node with 20 children, plus 48 × 8 = 384 bytes of dense children. Total 641 bytes, padded to 648. Compared to the alternative — 48 pairs of (key, pointer) = 432 bytes but with a 48-element linear scan — DuckDB trades 200 bytes of memory for a guaranteed constant-time lookup.

Node256: no table at all

Node256 drops the indirection entirely: uint16_t count and a 256-entry array of NodePtr, indexed directly by the byte. 2 + 2048 = 2050 bytes. One array read, one cache line touched for the pointer itself.

So the ladder looks like this:

node	children	lookup	size (approx.)
`Node4`	≤ 4	linear scan over ≤ 4 bytes	40 B
`Node16`	≤ 16	linear scan over ≤ 16 bytes	152 B
`Node48`	≤ 48	`child_index[byte]` → dense array	648 B
`Node256`	≤ 256	direct array index	2056 B

The design goal: never waste more than about half the space, and keep the common case (a handful of children) in a node that is essentially free.

The thresholds are deliberately asymmetric

 cpp
 
 
// src/execution/index/art/node48.cpp:38
void Node48::DeleteChild(ART &art, NodePtr &node_ptr, const uint8_t byte) {
	{
		NodeHandle handle(art, node_ptr);
		auto &n = handle.Get<Node48>();

		// Free the child and decrease the count.
		NodePtr::FreeTree(art, n.children[n.child_index[byte]]);
		n.child_index[byte] = EMPTY_MARKER;
		n.count--;

		if (n.count >= SHRINK_THRESHOLD) {
			return;
		}
	}

	// Shrink to Node16.
	auto node48_ptr = node_ptr;
	Node16::ShrinkNode48(art, node_ptr, node48_ptr);
}

Node48 shrinks when it drops below 12 children, but Node16 only shrinks when it drops below 4. Growth happens at exactly 4, 16 and 48. The hysteresis is deliberate: if the thresholds were symmetric (shrink at ≤ 4, grow at 5), a node oscillating around 4 children would convert back and forth on every insert — the classic thrashing problem. With a gap of 4→12, the node has to lose 8 children before it converts back.

Node256 has the same idea with an even wider gap: it shrinks at ≤ 36, while Node48 grows at 49.

Nine allocators, one per node type

The ART never calls malloc. When the index is created, it sets up nine fixed-size allocators, one per node type:

 cpp
 
 
// src/execution/index/art/art.cpp:121
	// Initialize the allocators.
	SetPrefixCount(info);
	if (!allocators) {
		owns_data = true;
		auto prefix_size = NumericCast<idx_t>(prefix_count) + NumericCast<idx_t>(Prefix::METADATA_SIZE);
		auto &block_manager = table_io_manager.GetIndexBlockManager();
		const auto leaf256_size = GetNode256LeafSegmentSize(info, db.GetStorageManager().GetStorageVersion());

		AllocatorArray allocator_array = {
		 make_unsafe_uniq<FixedSizeAllocator>(prefix_size, block_manager),
		 make_unsafe_uniq<FixedSizeAllocator>(sizeof(Leaf), block_manager),
		 make_unsafe_uniq<FixedSizeAllocator>(sizeof(Node4), block_manager),
		 make_unsafe_uniq<FixedSizeAllocator>(sizeof(Node16), block_manager),
		 make_unsafe_uniq<FixedSizeAllocator>(sizeof(Node48), block_manager),
		 make_unsafe_uniq<FixedSizeAllocator>(sizeof(Node256), block_manager),
		 make_unsafe_uniq<FixedSizeAllocator>(sizeof(Node7Leaf), block_manager),
		 make_unsafe_uniq<FixedSizeAllocator>(sizeof(Node15Leaf), block_manager),
		 make_unsafe_uniq<FixedSizeAllocator>(leaf256_size, block_manager),
		};
		allocators = make_shared_ptr<AllocatorArray>(std::move(allocator_array));
	}

Nine separate allocators because each node type has a different fixed size. FixedSizeAllocator promises that every allocation is a slot of exactly segment_size bytes, which means:

a node never straddles a block boundary in a way that requires special handling,
the free-space tracking is a bitmask, not a general-purpose free list,
and the whole index is buffer-managed, so it can be checkpointed and paged back in.

The mapping from node type to allocator index is a switch:

 cpp
 
 
// src/execution/index/art/node.cpp:105
uint8_t NodePtr::GetAllocatorIdx(const NType type) {
	switch (type) {
	case NType::PREFIX:
		return 0;
	case NType::LEAF:
		return 1;
	case NType::NODE_4:
		return 2;
	case NType::NODE_16:
		return 3;
	case NType::NODE_48:
		return 4;
	case NType::NODE_256:
		return 5;
	case NType::NODE_7_LEAF:
		return 6;
	case NType::NODE_15_LEAF:
		return 7;
	case NType::NODE_256_LEAF:
		return 8;
	default:
		throw InternalException("Invalid node type for GetAllocatorIdx: %d.", type);
	}
}

Note the order matches the allocator array exactly: prefix, leaf, node4, node16, node48, node256, then the three nested-leaf types.

Packing the block: validity bitmask + segments

The FixedSizeAllocator constructor does a careful integer computation of how many fixed-size segments fit into one buffer block, interleaving the free-space bitmask with the payload:

 cpp
 
 
// src/execution/index/fixed_size_allocator.cpp:13
FixedSizeAllocator::FixedSizeAllocator(const idx_t segment_size, BlockManager &block_manager, MemoryTag memory_tag)
 : block_manager(block_manager), buffer_manager(block_manager.buffer_manager), memory_tag(memory_tag),
 segment_size(segment_size), total_segment_count(0) {
	if (segment_size > block_manager.GetBlockSize() - sizeof(validity_t)) {
		throw InternalException("The maximum segment size of fixed-size allocators is " +
		 to_string(block_manager.GetBlockSize() - sizeof(validity_t)));
	}

	// calculate how many segments fit into one buffer (available_segments_per_buffer)

	const idx_t block_size = block_manager.GetBlockSize();
	const idx_t bits_per_value = sizeof(validity_t) * 8;

	// each full validity_t value is followed by bits_per_value segments: skip all of them at once
	const idx_t full_value_bytes = sizeof(validity_t) + bits_per_value * segment_size;
	const idx_t full_value_count = block_size / full_value_bytes;
	idx_t byte_count = full_value_count * full_value_bytes;

	bitmask_count = full_value_count;
	available_segments_per_buffer = full_value_count * bits_per_value;

	while (byte_count < block_size) {
		if (!bitmask_count || (bitmask_count * bits_per_value) % available_segments_per_buffer == 0) {
			// we need to add another validity_t value to the bitmask, to allow storing another
			// bits_per_value segments on a buffer
			bitmask_count++;
			byte_count += sizeof(validity_t);
		}

		auto remaining_bytes = block_size - byte_count;
		auto remaining_segments = MinValue(remaining_bytes / segment_size, bits_per_value);

		if (remaining_segments == 0) {
			break;
		}

		available_segments_per_buffer += remaining_segments;
		byte_count += remaining_segments * segment_size;
	}

	bitmask_offset = bitmask_count * sizeof(validity_t);
}

The layout of a block is: a run of validity_t bitmask words at the front, then the segment area. Each bit in the mask says “this segment is free”. The loop above is computing how many segments actually fit, accounting for the bitmask words themselves — a fixed-point calculation, because adding a bitmask word reduces the space left for segments, which may require adding another bitmask word.

Allocation itself is a bit-scan plus a bump:

 cpp
 
 
// src/execution/index/fixed_size_allocator.cpp:56
IndexPointer FixedSizeAllocator::New() {
	// No more free segments available.
	if (!buffer_with_free_space.IsValid()) {
		// Add a new buffer.
		auto buffer_id = GetAvailableBufferId();
		buffers[buffer_id] = make_shared_ptr<FixedSizeBuffer>(block_manager, memory_tag);
		buffers_with_free_space.insert(buffer_id);
		buffer_with_free_space = buffer_id;

		// Set and initialize the bitmask of the new buffer.
		D_ASSERT(buffers.find(buffer_id) != buffers.end());
		auto &buffer = buffers.find(buffer_id)->second;

		// Get a handle to the buffer's validity mask (offset 0).
		SegmentHandle handle(*buffer, 0);
		const auto bitmask_ptr = handle.GetPtr<validity_t>();
		ValidityMask mask(bitmask_ptr, available_segments_per_buffer);
		mask.SetAllValid(available_segments_per_buffer);
	}

	// Extract an index pointer to a free segment.

	D_ASSERT(buffer_with_free_space.IsValid());
	auto buffer_id = buffer_with_free_space.GetIndex();

	D_ASSERT(buffers.find(buffer_id) != buffers.end());
	auto &buffer = buffers.find(buffer_id)->second;
	auto offset = buffer->AllocateSegment(bitmask_count, available_segments_per_buffer);

	total_segment_count++;

	// If the buffer is full, we cache the next buffer that we're going to fill.
	if (buffer->segment_count == available_segments_per_buffer) {
		buffers_with_free_space.erase(buffer_id);
		NextBufferWithFreeSpace();
	}

	return IndexPointer(uint32_t(buffer_id), offset);
}

Note the return type: an IndexPointer, not a raw address. The allocator never hands out a pointer into memory — it hands out a buffer id and an offset, because the block may not be resident in memory at all. If it is not resident, the index has to page it in before dereferencing.

The packed 64-bit pointer

This is the piece that makes the whole thing work, and it is worth reading twice:

 cpp
 
 
// src/include/duckdb/execution/index/index_pointer.hpp:87
	//! Bit layout:
	//! MSB LSB
	//! 63 56 55 32 31 0
	//! +------------+--------------------------+------------------------------------+
	//! | Metadata | Offset | Buffer ID |
	//! | 8 bits | 24 bits | 32 bits |
	//! +------------+--------------------------+------------------------------------+
	//! NOTE: we do not use bit fields because when using bit fields Windows compiles
	//! the IndexPointer class into 16 bytes instead of the intended 8 bytes, doubling the
	//! space requirements
	//! https://learn.microsoft.com/en-us/cpp/cpp/cpp-bit-fields?view=msvc-170
	idx_t data;

Three fields in one word:

Buffer ID, 32 bits — which block-manager buffer this node lives in.
Offset, 24 bits — the segment index within that buffer. 24 bits is 16 million segments, which at ~40 bytes per segment is plenty for one block.
Metadata, 8 bits — the node type, plus a gate flag.

The metadata byte is the interesting one, because it makes the pointer self-describing. You do not need to load the node to know what kind of node it is:

 cpp
 
 
// src/include/duckdb/execution/index/art/node.hpp:183
	//! Returns the node type.
	inline NType GetType() const {
		return NType(GetMetadata() & ~AND_GATE);
	}

	//! True, if the node is a Node4, Node16, Node48, or Node256.
	bool IsInternalNode() const;
	//! True, if the node is a Node7Leaf, Node15Leaf, or Node256Leaf.
	bool IsNestedLeaf() const;
	//! True, if the node is any leaf.
	bool IsAnyLeaf() const;

	//! Get the row ID (8th to 63rd bit).
	inline row_t GetRowId() const {
		return UnsafeNumericCast<row_t>(Get() & AND_ROW_ID);
	}
	//! Set the row ID (8th to 63rd bit).
	inline void SetRowId(const row_t row_id) {
		Set((Get() & AND_METADATA) | UnsafeNumericCast<idx_t>(row_id));
	}

GetType() is a shift and a mask — no memory access at all. And the “8th to 63rd bit” comment on the row id is literal: the low 56 bits of the word hold the row id when the node is an inlined leaf.

That means a single-row leaf needs no allocation whatsoever:

 cpp
 
 
// src/execution/index/art/leaf.cpp:16
void Leaf::New(NodePtr &node_ptr, const row_t row_id) {
	D_ASSERT(row_id < MAX_ROW_ID_LOCAL);
	node_ptr.Clear();
	node_ptr.SetMetadata(static_cast<uint8_t>(INLINED));
	node_ptr.SetRowId(row_id);
}

The “pointer” to the leaf is the row id. The ART’s most common case — one row per distinct key — costs zero bytes of tree.

And the top bit of the metadata byte is repurposed as the “gate” flag, used when a key has duplicate values and the ART has to descend into a nested leaf.

The comment at the bottom of the IndexPointer is worth internalising: C++ bitfields would have been the natural way to write this, but MSVC pads the struct to 16 bytes instead of 8, doubling the memory. So DuckDB wrote the bit manipulation by hand. A 64-bit word, shifted and masked.

The keys are not raw bytes

One last detail, because it explains why byte-wise radix ordering gives you the ordering you expect. String keys are escaped before they enter the tree:

 cpp
 
 
// src/execution/index/art/art_key.cpp:20
template <>
ARTKey ARTKey::CreateARTKey(ArenaAllocator &allocator, string_t value) {
	auto string_data = const_data_ptr_cast(value.GetData());
	auto string_len = value.GetSize();

	// We escape \00 and \01.
	idx_t escape_count = 0;
	for (idx_t i = 0; i < string_len; i++) {
		if (string_data[i] <= 1) {
			escape_count++;
		}
	}

	idx_t key_len = string_len + escape_count + 1;
	auto key_data = allocator.Allocate(key_len);

	// Copy over the data and add escapes.
	idx_t pos = 0;
	for (idx_t i = 0; i < string_len; i++) {
		if (string_data[i] <= 1) {
			// Add escape.
			key_data[pos++] = '\01';
		}
		key_data[pos++] = string_data[i];
	}

	// End with a null-terminator.
	key_data[pos] = '\0';
	return ARTKey(key_data, key_len);
}

Bytes 0x00 and 0x01 are escaped with 0x01, and the key is NUL-terminated. The escaping means a byte in the data can never be confused with the terminator, so "abc" and "abc\0" cannot collide, and the radix ordering of the escaped bytes matches the ordering of the original strings.

The costs and trade-offs

The Node48 index table is 256 bytes of mostly zeros. For a node with 20 children, 236 of those bytes are EMPTY_MARKER. That is a deliberate memory-for-speed trade: DuckDB chose O(1) lookup over a dense 48-entry scan.

Each node type has its own allocator, so each has its own fragmentation. A Node4 and a Node256 cannot share a block, because their segment sizes differ. A tree with a mix of node types has a mix of block pools.

Prefix compression has a cost when keys do not share prefixes. If your keys are random 32-byte hashes, every prefix node holds 32 bytes of key and one child — the compression buys nothing and you pay a node per key.

24-bit offsets bound the block size. The offset field can address 16 777 216 segments. That is plenty today, but it is a hard ceiling on how large a single allocator block can be at a given segment size.

The ART is a byte radix tree. That is great for strings and fixed-width integers, and less great for types whose ordering is not byte ordering — DECIMAL with a scale, TIMESTAMP with time zones, or a DOUBLE (where the IEEE bit pattern ordering is not the numeric ordering). DuckDB handles this at the key-construction layer, not in the tree.

Hash tables are still faster for equality. An ART gives you ordered traversal and range scans for free. For a pure point lookup, a hash table probe is typically cheaper than walking several radix levels. The ART earns its place when you need ORDER BY over the indexed column, or a range predicate.

The bottom line

The ART is a good example of a data structure that is really a set of layout decisions rather than an algorithm.

Prefix nodes remove the need to compare bytes that are the same for every key under a node. The tree depth becomes a function of how much the keys differ, not how long they are.
The fanout ladder means the memory a node costs is proportional to the branching it actually does. A tree with a million nodes is mostly Node4s.
Fixed-size allocators per node type turn allocation into a bit-scan, make the tree buffer-manager-managed (so it can be spilled and checkpointed), and guarantee that a node is a known-size slot.
The packed pointer is what makes the rest possible: one 64-bit word carries the location and the type, so the engine can dispatch on node type without loading the node, and can pack a row id into the pointer of a leaf that then costs nothing.

And the reason all of it fits together is the decision to make the pointer self-describing. Everything else — the fixed-size allocators, the per-type pools, the metadata byte — is downstream of that one idea.

Art on Opensource internals