stout
The case for stout

You didn't install a package manager to wait.

Homebrew is the de facto package manager for macOS and Linux developers. It's also painfully slow. Every brew install starts with 500ms of Ruby interpreter warmup, a sequential download chain, and — if you haven't run brew update recently — a full git pull of a 700MB repository.

stout is the drop-in replacement that makes all of that disappear. Same formulae, same taps, same directory structure — but 10-100x faster, because the architecture is fundamentally different.

Why Homebrew is slow

Homebrew's performance is limited by three architectural decisions that made sense in 2009 but don't hold up at scale:

  • Ruby interpreter startup: Every brew invocation loads the Ruby runtime, which takes ~500ms before any work begins. stout starts in ~5ms as a native compiled binary.
  • Git-based metadata: Homebrew stores all formula metadata in a git repository (homebrew-core). Running brew update means pulling hundreds of megabytes of git objects. stout uses a pre-computed ~3MB SQLite database with FTS5 full-text search indices.
  • Sequential downloads: Homebrew downloads packages one at a time. stout uses Tokio's async runtime to download multiple packages in parallel.

What stout does differently

stout uses a hybrid architecture designed for speed:

  • Pre-computed index: A CI/CD pipeline transforms the Homebrew API data into a compressed SQLite database (~3MB with zstd). This index includes FTS5 search tables, dependency graphs, and bottle URLs — everything you need for instant queries.
  • Native Rust binary: No interpreter, no JIT warmup. The stout binary is a single statically-linked executable that starts in milliseconds.
  • Parallel downloads: Tokio's async runtime fetches multiple bottles simultaneously, saturating your network connection instead of waiting for one package at a time.
  • On-demand fetching: stout only downloads the metadata and bottles you actually need — no syncing 170,000+ formulae just to install one package.

The result

OperationHomebrewstoutSpeedup
--version500ms5ms100x
search json2-5s<50ms40-100x
info wget1-2s<100ms10-20x
update10-60s1-3s10-20x

Full compatibility, zero migration friction

stout is not a new package ecosystem. It installs the exact same bottles from the exact same Homebrew infrastructure. Your existing Cellar, taps, and symlinks work unchanged. The only thing that changes is speed.

If stout doesn't support a command you need, it transparently falls back to the brew CLI. You can adopt stout incrementally — no big-bang migration required.

Frequently asked

Why is Homebrew slow?
Homebrew is written in Ruby, which adds ~500ms of interpreter startup to every command. It also clones a ~700MB git repository for package metadata and downloads packages sequentially. stout eliminates all three bottlenecks with a native Rust binary, a pre-computed SQLite index, and parallel downloads.
Do I have to uninstall Homebrew first?
No. stout reads the same Cellar directory and works alongside Homebrew. You can migrate gradually — use stout for new installs while keeping your existing Homebrew packages.
Will my existing packages break?
No. stout writes compatible INSTALL_RECEIPT.json files and uses the same symlink structure. Packages installed by Homebrew are fully visible to stout, and vice versa.
How does stout handle formulae updates?
Instead of git-pulling a 700MB repository, stout downloads a compressed ~3MB SQLite index that is rebuilt daily. Updates take 1-3 seconds instead of 10-60 seconds.

Need Rust performance engineering or AI agent expertise?

Neul Labs — the team behind stout — consults on Rust development, performance optimization, CLI tool design, and AI agent infrastructure. We build fast, reliable systems that ship.