Running Git on Object Storage: A Technical Deep Dive into Remaking Packfiles

Why Git Struggles to Run Directly on Object Storage

Git, as a distributed version control system, was designed from the ground up around a local filesystem model. When developers try to deploy Git repositories directly on object storage like S3 or GCS, they run into a series of structural obstacles. The core tension is this: object storage excels at handling large, immutable data objects, while everyday Git operations involve heavy random reads and writes across many small files with frequent updates.

A typical Git repository contains thousands of loose objects and refs that change constantly during commits, merges, and garbage collection. Object storage lacks traditional filesystem semantics — no directory structure, no file locks, and no low-latency random access. Mapping Git directly onto object storage leads to severe performance degradation and consistency issues.

Packfiles Are the Key Breakthrough

The central insight from this Hacker News discussion is that if you're willing to re-make packfiles, Git can absolutely run on object storage.

A packfile is Git's bundling format — it compresses and consolidates large numbers of loose objects into a small number of large files, paired with an index file (.idx) for fast lookups. This design is a natural fit for object storage: packfiles are large, relatively immutable data blobs, exactly the kind of data object storage handles best.

From Loose Objects to Packed Objects

In a standard Git workflow, new commits are first written as loose objects, then packed later via git gc or git repack. If the storage backend is designed to always persist objects as packfiles, hundreds or thousands of small object writes can be batched into a handful of large uploads — dramatically reducing the number of object storage API calls and their associated latency overhead.

This is also what "re-make packfiles" means in practice: rather than treating every Git object as an independent storage object, you periodically repack them so that the granularity of storage-layer operations aligns with the cost model of object storage.

At the implementation level, a packfile consists of three parts: a magic number and version header, an object data section (each object stored with zlib compression, with delta encoding for further compression of similar content), and a trailing SHA-1 checksum. The companion .idx file provides a mapping from object hashes to offsets within the packfile, so individual objects can be located without scanning the entire pack. The v2 index format introduced in Git 2.x also supports packfiles larger than 4GB. In an object storage context, the .idx file can be cached in memory or on local disk, with range requests to object storage only issued when actual object content is needed. This separation is a key prerequisite for achieving acceptable latency in this architecture.

The Real-World Trade-offs

Building Git on top of object storage isn't without cost. The key trade-offs include:

• Write amplification: Repacking may require reading old packfiles, merging in new objects, and writing everything back. Frequent repacking introduces additional I/O and bandwidth costs.
• Refs and concurrency control: Ref updates require strong consistency guarantees, but most object storage systems only offer eventual consistency. Avoiding conflicts requires either an external metadata service or conditional write mechanisms.
• Read latency: Even with packfiles, fetching a single object may still trigger a range request, with higher latency than local disk access.

In short, this approach solves the question of whether Git can run on object storage — but how well it runs still depends on careful design of packing strategies, caching layers, and metadata management.

The consistency problem around refs is particularly tricky from an engineering standpoint. Git refs like refs/heads/main are essentially small files that update frequently, and traditional implementations rely on atomic filesystem write semantics (write-then-rename). On object storage, AWS S3 only offered eventual consistency before 2020, though it now supports strong read-after-write consistency; GCS provides similar guarantees. But compare-and-swap semantics for concurrent multi-client pushes still require an external coordination layer. Existing projects — such as certain backend explorations in Gitaly, and branching models in database-style projects like Neon and Dolt — typically host ref metadata in a dedicated strongly-consistent store (e.g., etcd, PostgreSQL) while offloading large packfile data to object storage, forming a hybrid architecture.

Implications for Cloud-Native Version Control

The broader value of this approach is that it points toward a larger trend: rearchitecting traditional developer tools — originally designed for local environments — to take advantage of cloud storage economics and elasticity. Object storage is cheap, near-infinitely scalable, and natively replicated. If Git can run efficiently on top of it, the door opens to hosting massive repositories at scale, stateless CI/CD build caches, and lightweight on-demand collaboration models.

It's worth noting that this discussion received limited traction on Hacker News (10 points, 1 comment) — it's more of a technical exploration than a production-ready proposal. Its value lies more in its conceptual provocation than in engineering conclusions: it's a reminder that many seemingly fundamental incompatibilities between technologies can often be bridged by rethinking the granularity at which data is organized.

Summary

The challenge of combining Git with object storage is fundamentally a mismatch between data access granularity and storage medium characteristics. By remaking packfiles — aggregating large numbers of small objects into a handful of large ones — you can align Git's storage model with the strengths of object storage. This offers a pragmatic entry point for building cloud-native version control infrastructure, even as significant engineering challenges around consistency, write amplification, and latency remain to be solved.