GitGres stores all git objects, refs, PRs, issues, and metadata in Postgres rows, replacing GitHub with a self-hosted server tunable for cost, latency, and consistency.
Key Takeaways
Everything (blobs, packfiles, deltas, tokens, PRs, issues, comments, reviews, orgs, events) lives in Postgres; the server holds nothing on disk.
Supports smart HTTP (v1+v2), gh CLI via a generated hosts.yml entry, and a custom gitgres:: remote helper that connects directly to Postgres.
Three tuning axes: cost vs. uptime (tiered storage), latency vs. cost (Postgres cache layer), consistency vs. throughput (local or colocated deployment).
Setup is four steps: cargo build, point GITGRES_DB at a Postgres instance, gitgres init for idempotent schema, then gitgres serve with a bootstrap admin token.
Current gaps: no search, no Actions/workflows/secrets, no SSH transport, no webhooks, no HTTP/2, no web UI.
Hacker News Comment Review
The core question from commenters is use-case differentiation: why GitGres over existing self-hosted options like Forgejo or GitLab, which already handle private git hosting.
One commenter probed the object model: how Git’s content-addressable blobs map to Postgres (bytea vs. JSONB), raising a real schema design question the README does not answer.
A reply noted that building on an ACID-compliant store could justify tighter referential structure than Git’s loose filesystem model, suggesting the Postgres backend may enable a cleaner internal graph.
Notable Comments
@vishal_ch: Asks specifically whether blobs are stored as bytea or commit graphs as JSONB trees – a concrete schema gap in the current docs.
