ARCHIL
All comparisons

Archil vs Amazon EFS

Pick Amazon EFS for managed NFS deep in AWS (IAM, VPC, AWS Backup, EKS), shared NFS locks, or the fastest large sequential and random writes. Pick Archil when agents work on many small files, where git, npm and SQLite transactions ran about 5x to 190x faster, or need branches, an S3 API and sandboxes.

Where Archil stands out

  • Faster on small files

    git, npm and SQLite transactions ran about 5x to 190x faster than on EFS in Archil's benchmark.

  • Branches and an S3 API

    Branch a disk in milliseconds and read the same files over S3.

  • Works beyond AWS

    Disks mount anywhere and sync with S3, GCS or R2.

Archil and Amazon EFS, side by side

What it is
Archil: Managed POSIX file system with an S3 API, plus Firecracker sandboxes
Amazon EFS: Managed, serverless NFS on AWS
Protocol
Archil: Own protocol over FUSE; delegations acknowledge creates and writes locally
Amazon EFS: NFS; every create, rename or attribute change round-trips to the server
Many clients at once
Archil: Yes, up to 5,000 per disk
Amazon EFS: Yes, including ReadWriteMany for EKS pods via the EFS CSI driver
Snapshots and branches
Archil: Checkpoint p50 13 ms, branch p50 33 ms, any size
Amazon EFS: No native branching or checkpoints
Object storage
Archil: Syncs both ways with S3, GCS, R2 or S3-compatible; every disk is an S3 bucket
Amazon EFS: No S3 API to the file data
Running agent code
Archil: Firecracker sandboxes on a disk
Amazon EFS: Not included; pair with separate compute isolation
Billing model
Archil: Active storage per GiB-month
Amazon EFS: Per GB-month by class, plus throughput; IA and Archive bill at least 128 KiB per file

Measured on one EC2 host

MethodFrom the benchmark on docs.archil.com: one AWS c7gn.2xlarge in us-east-1, a new Archil disk with default mount options, and Amazon EFS in General Purpose mode with Elastic throughput and Standard storage, mounted with amazon-efs-utils (TLS, NFSv4.1). Git clones came from local mirrors and npm from a filled cache, so only the file system was measured. Medians of 3 runs. Run it yourself.

git clone, react (7,260 files)

Lower is better
  • Archil9.80 s
  • Amazon EFS1 min 22 s

npm ci, create-next-app (~20k files)

Lower is better
  • Archil7.60 s
  • Amazon EFS1 min 26 s

SQLite, 10k single-row transactions (synchronous=FULL)

Lower is better
  • Archil23.9 s
  • Amazon EFS8 min 43 s

SQLite, one bulk insert of 1M rows

Lower is better
  • Archil11.0 s
  • Amazon EFS1.70 s

Sequential write, 4 GiB + fsync

Higher is better
  • Archil194 MB/s
  • Amazon EFS590 MB/s

4 KiB random reads, cold

Higher is better
  • Archil4,086 IOPS
  • Amazon EFS1,298 IOPS

Benchmark

One AWS c7gn.2xlarge in us-east-1; EFS General Purpose, Elastic throughput, Standard storage. Medians of 3 runs. Methodology.

git clone, react (7,260 files)
Archil: 9.8 s
Amazon EFS: 81.5 s
git status, react
Archil: 0.55 s
Amazon EFS: 2.6 s
git checkout of an old tag, react (8,158 files change)
Archil: 1.06 s
Amazon EFS: 46.9 s
npm ci, create-next-app (598 packages, ~20k files)
Archil: 7.6 s
Amazon EFS: 86.3 s
rm -rf node_modules
Archil: 1.5 s
Amazon EFS: 83.3 s
SQLite: 10k single-row transactions, synchronous=FULL
Archil: 23.9 s
Amazon EFS: 523 s
SQLite: 100k random point reads
Archil: 7.0 s
Amazon EFS: over 10 min (stopped)
SQLite: bulk insert of 1M rows in one transaction
Archil: 11.0 s
Amazon EFS: 1.7 s
Sequential write, 1 MiB blocks, 4 GiB + fsync
Archil: 194 MB/s
Amazon EFS: 590 MB/s
Sequential read, cold
Archil: 1,197 MB/s
Amazon EFS: 1,020 MB/s
4 KiB random read, cold
Archil: 4,086 IOPS
Amazon EFS: 1,298 IOPS
4 KiB random write, 30 s + fsync
Archil: 953 IOPS
Amazon EFS: 2,976 IOPS

How they differ

Architecture

EFS is mature, serverless NFS, built for many clients sharing large files at high throughput.

Agent work is the opposite: clones, installs and SQLite, all small files and metadata. NFS can't cache a mutating metadata operation, so each one waits on the server. Archil clients take delegations and talk to several storage servers in parallel.

Where the performance gap comes from

Archil leads on small files and transactions, about 8x on a react clone and 22x on SQLite transactions. EFS leads on large sequential writes, 4 KiB random writes and one bulk SQLite insert, so "uses SQLite" alone doesn't pick a file system.

Persistence and sharing

EFS's CSI driver survives pod restarts, node replacements and cluster upgrades, and its NFS locks are shared across clients.

An Archil disk mounts in shared or conditional mode. A write is durable when fsync returns, designed for 99.999% durability across Availability Zones, and checkouts give one client exclusive writes to a path.

Branching agent workspaces

On EFS, teams build branching themselves, for example with checkpoints to S3. Each Archil branch is an independent writable disk: one per agent attempt, or a rollback after a failed run.

Object storage and running code

EFS is a file system only. Archil's S3 API is strongly consistent with the file system, a disk can sync to your bucket as ordinary objects, and Archil sandboxes keep the agent's code next to its files.

Pricing model

On EFS, each file's 2 KiB of metadata stays in Standard, so small-file workspaces gain little from tiering. See Amazon EFS pricing.

Archil has a lower archive rate for colder data on Archil-managed disks, and copy-on-write branches bill shared data once. See Archil pricing.

Which one should you use?

Use Amazon EFS when

  • you want IAM, VPC, AWS Backup and EKS integration without another vendor
  • apps rely on shared NFS file locks
  • large sequential writes, random writes or bulk inserts dominate
  • you already run EFS under AWS-anchored compliance

Use Archil when

  • agents clone, install and run SQLite transactions
  • each attempt needs its own branch in milliseconds
  • you need the files over S3, or data in GCS or R2
  • compute runs outside AWS, or agents need a sandbox next to the data

Questions people ask

More comparisons

Or see every comparison, grouped by sandboxes, file systems and object storage.