btype: Best Go Collections Libraries for Go Devs in 2026

What Is btype?

btype is a Go collections library from Tidwall that packages B-tree-backed maps, sets, arrays, tables, stacks, queues, deques, and priority queues into one API. btype is one of the best Go Collections Libraries tools for Go developers building ordered, snapshot-friendly in-memory data structures. The repo advertises O(log n) operations, O(1) copy-on-write snapshots, and 100% test coverage, which matters when you need deterministic ordering instead of hash-map randomness.

Quick Overview

Who Should Use btype?

• Backend engineers building leaderboards, ordered indexes, or time-sorted records who need range scans and stable iteration.
• Platform teams that want a typed, reusable collection layer instead of ad hoc slices, maps, and custom sorting code.
• Library authors exposing ordered data structures in Go APIs where predictable traversal and index access are part of the contract.
• Indie hackers shipping small services that need snapshotting, fast range deletes, and less manual bookkeeping around sorted state.

Not ideal for:

• Workloads that only need constant-time hash lookups and never sort, where a plain map is simpler.
• Highly concurrent mutation across many goroutines without an external lock, because btype does not replace synchronization.
• Tiny collections where a slice plus sort is faster to read, easier to debug, and cheaper to maintain.

Key Features of btype

• B-tree ordered storage — Every collection is backed by a B-tree, so inserts, deletes, seeks, and range walks stay logarithmic. That is a better fit than flat slices when the data set changes often and still needs ordering.
• Copy-on-write snapshots — Copy() returns an O(1) shadow clone, which is useful for read-heavy workloads, speculative updates, and undo-like flows. Release() is optimized for copied collections, so cleanup can be cheaper than a full deep free.
• Counting-tree random access — The package uses B-tree counting so GetAt, InsertAt, DeleteAt, and IndexOf stay O(log n) instead of collapsing into linear scans. That makes index-based mutations practical on sorted structures.
• Iterator-first API — All(), Backward(), Ascend(), Descend(), Drain(), and related methods return iter.Seq or iter.Seq2 values. The result is a clean for range style that fits modern Go without custom iterator plumbing.
• Multiple collection shapes — btype ships Map, Set, Array, Table, Stack, Queue, Deque, and Prique in one package. That reduces dependency sprawl when a service needs more than one ordered primitive.
• Range and seek operations — Seek, SeekNext, SeekPrev, DeleteRange, and DeleteRangeAt are built for ordered workloads. These APIs are exactly what you want for time windows, key prefixes, and batched cleanup.
• Low-memory, well-tested design — The repo states 100% coverage and a low-memory focus, which is a good sign for code that will sit in hot paths. For infrastructure code, predictable memory behavior often matters more than a flashy API.

btype vs Alternatives

Pick google/btree if you want a smaller dependency and you only need the classic ordered tree API. Choose tidwall/btree if you want the underlying tree primitive and plan to build your own abstractions on top.

Use frozenca/BTree when you are comparing implementations or need a reference for custom tree behavior. If you are profiling whether a migration is worth it, pair that work with OpenTrace so you can measure allocation churn and latency before committing to a tree-based design. For adjacent tooling, browse all developer tools if you are building a broader Go workflow.

How btype Works

btype uses a B-tree as the core abstraction, which keeps keys in sorted node pages instead of leaving ordering to a post-processing step. That design gives you logarithmic inserts and deletes, plus fast ordered iteration for structures like Map, Set, and Table.

The Map and Set types use cmp.Ordered and cmp.Compare for natural ordering, while Table can sort by key fields or a custom compare function. That makes btype useful when the order is part of the domain model, such as ranking lists, journaled records, or index-like caches.

The standout design choice is copy-on-write shadow cloning. Copy() does not immediately duplicate the full tree, so you can snapshot state cheaply and only pay for mutation when a branch diverges. The package also uses B-tree counting so GetAt and DeleteAt stay logarithmic, which is why btype can serve both key-based and index-based access patterns.

go test github.com/tidwall/btype -run Test -count=1

That command forces the package through its test suite and is a quick sanity check that your Go toolchain can resolve the module cleanly. In practice, the same core tree is what powers the collection types, so if the tests pass you can trust the ordered behavior exposed by Map, Set, Queue, and friends.

Pros and Cons of btype

Pros:

• One package covers many ordered data structures — You get map, set, array, table, stack, queue, deque, and priority queue support without stitching together multiple dependencies.
• Logarithmic mutation and lookup — The B-tree core keeps writes, seeks, and range operations at O(log n), which is the right shape for growing ordered datasets.
• Cheap snapshots — Copy() is O(1), so you can clone state for reads, retries, or branching workflows without deep-copying the full collection.
• Modern iteration style — The iter.Seq and iter.Seq2 APIs integrate cleanly with for range and reduce iterator boilerplate.
• Index-based access is built in — GetAt, InsertAt, and DeleteAt save you from converting ordered collections into slices just to touch a position.
• Testing and memory focus — The repo emphasizes 100% coverage and low memory use, both of which are good signals for a library that may sit in performance-sensitive code.

Cons:

• More complex than a plain map — If you do not need ordering, a hash map is simpler and usually faster for direct lookup.
• Snapshot semantics add mental overhead — Copy-on-write is efficient, but teams need to understand when state is shared and when it diverges.
• No built-in concurrency layer — You still need external locking or higher-level coordination for concurrent writes.
• Can be overkill for tiny datasets — Small slices often beat tree structures on raw simplicity and sometimes on absolute speed.
• Broader API surface means more to learn — The package is tidy, but it exposes enough operations that new users should read the method set before adopting it broadly.

Getting Started with btype

go mod init example.com/btype-demo
go get github.com/tidwall/btype@latest
go test ./...

Those commands create a module, download btype, and verify that your workspace resolves dependencies correctly. The next step is to define a typed collection such as var users btype.Map[string, string], then call Set, All, Seek, or Copy depending on whether you need ordered iteration, indexed access, or snapshotting.

Verdict

btype is the strongest option for Go services that need ordered collections when range scans, index access, and cheap snapshots all matter. Its best strength is the combination of B-tree ordering and copy-on-write cloning. The main caveat is that it is not a replacement for a plain map when you only need direct lookup. Use it when order is part of the data model, and skip it when simplicity wins.