Rust-first · Agent-ready · RandRW-optimized

BrewFSRust-native filesystem for multi-agent collaborative read/write workloads.

BrewFS gives multiple agents a shared POSIX-like workspace, optimized for RandRW-heavy access patterns and backed by a transparent Rust-native storage engine.

15/24

matched rows led vs JuiceFS (10/14 data-path, 5/10 metadata).
Highlights: 37% faster random read, 51% foreground mixed I/O, 92% drained mixed — README benchmark snapshot.

Redis + RustFS · single-node deployment

# install BrewFS in single-node mode
curl -fsSL https://raw.githubusercontent.com/brewfs/brewfs/main/scripts/install_brewfs_single_node.sh \
  | sudo bash -s -- install

View Agent Workloads See RandRW Benchmark Test Method

Multi-Agent Read / WriteRandRW OptimizedRust NativePOSIX-like FUSEShared WorkspaceChunk / Block / SliceS3-compatiblePluggable Metadata

15/24

matched rows led vs JuiceFS

37%

faster random read

51%

faster foreground mixed I/O

92%

faster fully drained mixed I/O

Built for Agentic IO

Agent workloads are not simple sequential reads.

Agents continuously scan repositories, read context files, write intermediate artifacts, update memory, generate logs, modify working directories, and exchange outputs with other agents. BrewFS is designed for this mixed random read/write pattern.

⟲

Random Read

Agents frequently read source files, configuration, context documents, memory snapshots, and intermediate results.

✎

Random Write

Agents continuously write patches, logs, state files, reports, temporary outputs, and generated artifacts.

⌗

Metadata-heavy Access

Agents repeatedly walk directories, check file attributes, test file existence, and scan project structures.

⧉

Shared Workspace

Multiple agents collaborate in the same filesystem namespace and consume each other's outputs.

⇄

Artifact Exchange

Agents exchange code, plans, caches, indexes, reports, and execution results through normal file paths.

≣

Concurrent Updates

Multiple agents read and write different files, directories, and workflow stages at the same time.

Multi-agent Shared Workspace

One shared workspace for many agents

BrewFS gives multiple agents a shared filesystem workspace. Agents keep using normal file APIs while BrewFS handles concurrent metadata updates, random read/write IO, object block layout, and background compaction.

Agents read context, write artifacts, update task state, and hand off results.
No dedicated agent-storage protocol — the filesystem is the coordination layer.
Easy for humans to inspect; easy for infrastructure teams to persist on object storage.

Agent Aplanner

Agent Bexecutor

Agent Creviewer

Agent Dreporter

Shared POSIX-like WorkspaceBrewFS · VFS over FUSE

Metadata Backend

Redis / etcd / TiKV
Namespace · Inode · Slice metadata

Chunk / Object Engine

Chunk · Block · Slice
LocalFS / S3-compatible storage

Core Advantages

A transparent storage stack, not a black box

RandRW

Optimized for Agent Workloads

92% faster fully drained mixed I/O and 51% faster foreground mixed I/O versus JuiceFS in the July 24, 2026 Redis + RustFS snapshot — well suited for agents that read context, write artifacts, and scan directories.

WORKSPACE

Shared Space for Many Agents

Multiple agents collaborate through one POSIX-like namespace and exchange code, logs, plans, caches, and indexes.

RUST

Rust-native IO Pipeline

From FUSE requests to FileWriter, SliceState, ObjectBlockStore, and metadata commits — the IO path is organized in Rust.

LAYOUT

Layer-aware Data Layout

Chunk, Block, and Slice are first-class concepts, making random IO, object layout, compaction, and GC easy to reason about.

METADATA

Backends for Concurrent Agents

Pluggable metadata backends — SQLx, Redis, etcd, TiKV — let teams explore latency, consistency, and operational trade-offs.

OBJECT

S3-compatible Artifact Storage

Agent-generated artifacts, logs, indexes, and checkpoints land on LocalFS or S3-compatible object storage.

BENCHMARK

Transparent Benchmarking

RandRW, metadata-heavy access, small-file workloads, and multi-agent scaling are first-class benchmark scenarios.

DEVELOPER

Developer-first Stack

Not just a mounted directory — a transparent stack developers can inspect, benchmark, modify, and extend.

Architecture

Transparent storage architecture

BrewFS separates filesystem semantics, metadata transactions, object-block storage, and background maintenance into clear layers — usable, inspectable, testable, and extensible.

Explore the architecture

APPApplications / AgentsAI Jobs · Containers · CLI · SDK

↓ POSIX-like FUSE

VFSVFS Layerpath · inode · handle · read/write · rename

↓

METAMetadata LayerSQLx · Redis · etcd · TiKV

DATAChunk EngineChunk · Block · Slice · Cache · GC

↓

OBJObject BackendLocalFS / S3-compatible storage

Performance vs JuiceFS

Redis + RustFS benchmark snapshot

The README benchmark compares BrewFS and JuiceFS on the same host with Redis metadata, RustFS S3-compatible storage, compression disabled, matching writeback profiles, and buffered fio I/O. Writes are also measured after the post-write queue is fully drained.

Matched workload highlights relative to JuiceFS

higher is better ->

Mixed I/O (fully drained)

1.92x

Foreground Large write

1.90x

Foreground mixed I/O

1.51x

Random read

1.37x

Readdir

1.79x

Data throughput

Workload	BrewFS	JuiceFS	Ratio
Large read	194.34 MiB/s	194.17 MiB/s	~1.00x
Sequential read	740.60 MiB/s	1,000.76 MiB/s	0.74x
Random read	1,726.10 MiB/s	1,256.80 MiB/s	1.37x
Large write	195.05 MiB/s	102.40 MiB/s	1.90x
Sequential write	189.33 MiB/s	117.94 MiB/s	1.61x
Random write	178.17 MiB/s	117.43 MiB/s	1.52x
Mixed random I/O	495.54 MiB/s	328.76 MiB/s	1.51x
Mixed I/O (fully drained)	218.60 MiB/s	113.86 MiB/s	1.92x

Metadata throughput

Operation	BrewFS	JuiceFS	Ratio
Create	1,004.61 ops/s	549.01 ops/s	1.83x
Open	4,827.50 ops/s	11,883.85 ops/s	0.41x
Stat	726,234.51 ops/s	724,328.73 ops/s	~1.00x
Readdir	28,634.94 ops/s	16,020.25 ops/s	1.79x
Rename	894.64 ops/s	1,313.40 ops/s	0.68x

This is not a universal claim that BrewFS is faster in every deployment. It is a local engineering snapshot from July 24, 2026. BrewFS leads 15 of 24 matched rows; JuiceFS still leads sequential read, strictly drained pure writes, and TiKV create/open/rename. Raw fio JSON, profile env, logs, and generated reports are retained under docker/compose-xfstests/artifacts/. Read the README benchmark ->

BrewFS vs JuiceFS

JuiceFS is production-first.
BrewFS is Rust-first and Agent-ready.

JuiceFS is a mature cloud-native filesystem product for production deployments, multi-protocol access, and commercial support. BrewFS focuses on a different direction: a Rust-native storage engine, transparent storage layers, and high-performance RandRW for multi-agent workspaces.

Read BrewFS vs JuiceFS →

Rust Native

Designed around Rust, not just written in it

FUSE request handling, VFS operations, metadata clients, Chunk / Block / Slice layout, object IO, buffering, compaction, and GC are organized around Rust's ownership model, type boundaries, and async IO ecosystem.

Explore the Rust engine →

Quick Start

Run BrewFS locally

LocalFS + SQLite is the simplest way to run BrewFS and inspect its data layout. From there, move to S3-compatible object storage and metadata backends such as Redis, etcd, TiKV, or PostgreSQL.

Get Started Try the RandRW Benchmark

bash

mkdir -p /tmp/brewfs-mnt /tmp/brewfs-data

cargo run -p brewfs -- mount /tmp/brewfs-mnt \
  --data-backend local-fs \
  --data-dir     /tmp/brewfs-data \
  --meta-backend sqlx \
  --meta-url     sqlite:///tmp/brewfs-meta.db

Roadmap

Open roadmap, benchmark-driven development

BrewFS is open about what is implemented, what is being optimized, and what still needs validation.

Disk read cacheCompressionUnified Memory / IO BudgetIO priorityRate limitingAdaptive flushSlice coalescingPrefetch feedbackStrict consistency modeMulti-agent scaling benchmarksAgent workspace test suite

View the full roadmap →

Mount a filesystem you can understand, benchmark, and extend.

BrewFS is built for teams that don't only want to mount a filesystem, but also want to optimize the storage path for multi-agent workloads.

Get Started ★ Star on GitHub

BrewFSRust-native filesystem for multi-agent collaborative read/write workloads.

BrewFS gives multiple agents a shared POSIX-like workspace, optimized for RandRW-heavy access patterns and backed by a transparent Rust-native storage engine.

15/24

matched rows led vs JuiceFS (10/14 data-path, 5/10 metadata).
Highlights: 37% faster random read, 51% foreground mixed I/O, 92% drained mixed — README benchmark snapshot.

Redis + RustFS · single-node deployment

# install BrewFS in single-node mode
curl -fsSL https://raw.githubusercontent.com/brewfs/brewfs/main/scripts/install_brewfs_single_node.sh \
  | sudo bash -s -- install

Multi-Agent Read / WriteRandRW OptimizedRust NativePOSIX-like FUSEShared WorkspaceChunk / Block / SliceS3-compatiblePluggable Metadata

One shared workspace for many agents

Agents read context, write artifacts, update task state, and hand off results.

No dedicated agent-storage protocol — the filesystem is the coordination layer.

Easy for humans to inspect; easy for infrastructure teams to persist on object storage.

Workload

BrewFS

JuiceFS

Ratio

Large read

194.34 MiB/s

194.17 MiB/s

~1.00x

Sequential read

740.60 MiB/s

1,000.76 MiB/s

0.74x

Random read

1,726.10 MiB/s

1,256.80 MiB/s

1.37x

Large write

195.05 MiB/s

102.40 MiB/s

1.90x

Sequential write

189.33 MiB/s

117.94 MiB/s

1.61x

Random write

178.17 MiB/s

117.43 MiB/s

1.52x

Mixed random I/O

495.54 MiB/s

328.76 MiB/s

1.51x

Mixed I/O (fully drained)

218.60 MiB/s

113.86 MiB/s

1.92x

Operation

BrewFS

JuiceFS

Ratio

Create

1,004.61 ops/s

549.01 ops/s

1.83x

Open

4,827.50 ops/s

11,883.85 ops/s

0.41x

Stat

726,234.51 ops/s

724,328.73 ops/s

~1.00x

Readdir

28,634.94 ops/s

16,020.25 ops/s

1.79x

Rename

894.64 ops/s

1,313.40 ops/s

0.68x

mkdir -p /tmp/brewfs-mnt /tmp/brewfs-data cargo run -p brewfs -- mount /tmp/brewfs-mnt \ --data-backend local-fs \ --data-dir /tmp/brewfs-data \ --meta-backend sqlx \ --meta-url sqlite:///tmp/brewfs-meta.db

Agent workloads are not simple sequential reads.

Random Read

Random Write

Metadata-heavy Access

Shared Workspace

Artifact Exchange

Concurrent Updates

One shared workspace for many agents

Metadata Backend

Chunk / Object Engine

A transparent storage stack, not a black box

Optimized for Agent Workloads

Shared Space for Many Agents

Rust-native IO Pipeline

Layer-aware Data Layout

Backends for Concurrent Agents

S3-compatible Artifact Storage

Transparent Benchmarking

Developer-first Stack

Transparent storage architecture

Redis + RustFS benchmark snapshot

Data throughput

Metadata throughput

JuiceFS is production-first.BrewFS is Rust-first and Agent-ready.

Designed around Rust, not just written in it

Run BrewFS locally

Open roadmap, benchmark-driven development

Mount a filesystem you can understand, benchmark, and extend.

Agent workloads are not simple sequential reads.

Random Read

Random Write

Metadata-heavy Access

Shared Workspace

Artifact Exchange

Concurrent Updates

One shared workspace for many agents

Metadata Backend

Chunk / Object Engine

A transparent storage stack, not a black box

Optimized for Agent Workloads

Shared Space for Many Agents

Rust-native IO Pipeline

Layer-aware Data Layout

Backends for Concurrent Agents

S3-compatible Artifact Storage

Transparent Benchmarking

Developer-first Stack

Transparent storage architecture

Redis + RustFS benchmark snapshot

Data throughput

Metadata throughput

JuiceFS is production-first.BrewFS is Rust-first and Agent-ready.

Designed around Rust, not just written in it

Run BrewFS locally

Open roadmap, benchmark-driven development

Mount a filesystem you can understand, benchmark, and extend.

JuiceFS is production-first.
BrewFS is Rust-first and Agent-ready.

JuiceFS is production-first.
BrewFS is Rust-first and Agent-ready.