Technology

JuiceFS

A POSIX-compliant distributed filesystem that uses S3-compatible object storage as its data backend and a separate metadata engine (Redis, PostgreSQL, or TiKV) for file metadata.

3 connections 2 resources

Summary

What it is

A POSIX-compliant distributed filesystem that uses S3-compatible object storage as its data backend and a separate metadata engine (Redis, PostgreSQL, or TiKV) for file metadata.

Where it fits

JuiceFS bridges the gap between applications that expect POSIX filesystem semantics and data stored on S3. It enables ML training frameworks, legacy applications, and POSIX-dependent tools to access S3 data as a mounted filesystem — without rewriting code to use S3 APIs directly. Unlike simple FUSE mounts (GeeseFS, Mountpoint for S3), JuiceFS splits files into chunks stored as S3 objects with external metadata management.

Misconceptions / Traps
  • JuiceFS adds a metadata engine dependency (Redis, PostgreSQL, or TiKV). This is a stateful component that must be backed up, scaled, and monitored — it is not purely serverless.
  • POSIX compliance over S3 introduces latency overhead. Random reads and small file operations are slower than native filesystem access due to S3 round-trips for data chunks.
  • JuiceFS is not a FUSE mount that maps S3 objects 1:1 to files. It splits files into chunks stored as S3 objects with separate metadata, which is a fundamentally different architecture.
Key Connections
  • depends_on S3 — uses S3 as the data storage backend
  • solves Lack of Atomic Rename — atomic rename implemented in the metadata engine
  • scoped_to Object Storage — bridges POSIX and S3 semantics

Definition

What it is

A POSIX-compatible distributed filesystem that uses S3-compatible object storage as its data layer and a separate metadata engine (Redis, TiKV, or PostgreSQL) for file metadata. Bridges traditional filesystem semantics and object storage economics.

Why it exists

Many workloads — ML training frameworks, legacy analytics tools, POSIX-dependent applications — require filesystem semantics (atomic rename, directory listing, random reads) that S3 does not natively provide. JuiceFS layers these semantics on top of S3 without requiring application rewrites.

Primary use cases

POSIX filesystem access to S3-backed data for ML training, shared filesystem for Kubernetes pods backed by S3, legacy application integration with object storage.

Connections 3

Outbound 3
scoped_to1
Object Storage
depends_on1
S3
solves1
Lack of Atomic Rename

Resources 2

DocsHigh
juicefs.com/docs/community/introduction/

Architecture overview and S3 backend configuration for the POSIX-compatible distributed filesystem that bridges local file semantics with object storage.

GitHubHigh
github.com/juicedata/juicefs

Source code with metadata engine options (Redis, TiKV, PostgreSQL) and S3-compatible storage backend implementations.