Trade-offs and alternatives
Every design gives something up. This page states plainly what Synck gives up and compares it with the systems people most often ask about. If another tool fits your work better, you should use it. Synck earns its place only where its particular guarantees are what you need.
What the design costs
History takes space. Synck never discards accepted history, so a repository keeps growing even when its current files shrink. Chunked storage, the default, shares most of the storage between repeated saves of a large file, but each changed region still costs new space, so Synck suits documents better than a stream of large media revisions. Salted message bodies deliberately give up deduplication of identical messages. Verification reads the entire retained history and closure, so its cost grows with the history.
Concurrency has limits. Per-item conflict domains remove one unnecessary point of serialization, the global head, not every bottleneck. A heavily edited item, a large structural change, current-state updates in the acceptance transaction, and SQLite’s single writer can each dominate a workload. The history index and the sequencer move work out of acceptance, but add storage, backlog and recovery responsibilities. Nothing in the model guarantees a particular throughput or repository size.
One writer means no offline divergence. Two people cannot change separate copies of the same repository and combine their work later. For text that people edit in parallel, that is a serious limitation, and it is why Synck is not a replacement for Git in software development.
You cannot erase history. Append-only history is the guarantee, and also the limitation. A secret committed by mistake stays in every copy that includes that commit.
Compared with other systems
| System | Where it is strongest | What choosing Synck instead gives up |
|---|---|---|
| Git | Distributed source development, branches, merges, code review | Branch-based collaboration, independent local commit graphs, and Git’s ecosystem |
| Lore | Content-oriented version control for large assets, sparse and lazy access, revision graphs with branches | Its asset and branching model. Complete Synck copies favor carrying everything over fetching a subset |
| Perforce P4 | Centrally administered asset and source workflows, streams, exclusive checkout of unmergeable files | An established server and workspace model, and long-lived editing locks |
| An application database with history tables | Product-specific transactions and queries with modest history needs | A simpler schema that you fully own, without a separate event and format contract |
Git
Git names snapshots through trees and records parent commits. That graph is what makes branching and merging work. If your proposal is a text file discussed in a code-review tool, Git may solve the whole problem with less new machinery. Git can store serialized messages too, but then the application must define their identity, ordering and concurrency rules itself. Synck’s per-item history becomes useful when preserving application data and its relationships is the requirement. Git also supports sparse checkouts and partial clones. Choosing a complete Synck copy trades that selective fetching for having every retained byte present. Git’s own book explains its objects and branches.
Lore
Lore’s system design describes immutable content storage with mutable coordination, chunked content, sparse and lazy access, and revision graphs with branches and merges. Those address large asset workflows that a complete Synck repository does not replace. A team that needs a small slice of a huge binary tree should evaluate that model directly. Synck instead puts typed application history, and a fully present content closure, at the center of the portable copy. (Lore’s document describes its intended architecture. It is not a benchmark, and neither is this comparison.)
Perforce
Perforce documents streams and exclusive-open file types. For artists editing unmergeable assets under central administration, its workspace and locking model may fit more directly than building those services around Synck. Synck’s conflict locks only protect the moment of acceptance. They are not a person’s long-lived “I am editing this” lock, which in Synck would be the application’s job. Perforce also supports distributed work through personal servers. Central administration does not mean it lacks offline work.
An application database
If an application only needs current state and a short audit trail, a durable event vocabulary, canonical encoding rules, full historical closure and verification tooling are obligations it does not need. Synck earns that complexity when history must remain independently interpretable and copyable beyond the current service. For the launch example, the payoff is modest and testable: a complete copy keeps the same file identity, its older bytes, the review messages and their accepted history after the original application is gone.