Graft for partial SQLite replication at the edge

Graft's partial replication problem

Graft addresses applications that cannot treat full database replication as an acceptable default. Its documentation targets offline-first mobile software, cross-platform synchronization, stateless replicas, embedded deployments, and databases spread across unreliable or distributed environments. The central constraint is bandwidth. Instead of copying an entire database whenever a client or replica changes, Graft is designed to synchronize only the data required for a particular operation or update.

That distinction matters most when applications contain data that is relevant in different places. A location-aware application may need one subset on a mobile device, another subset on an edge worker, and the complete dataset in a central service. Graft describes this as lazy and partial replication. Lazy replication means data is synchronized on demand rather than eagerly maintained everywhere. Partial replication limits synchronization to required data. Together, these features attempt to reduce network transfer and computation without abandoning consistent transactional views.

The intended users are therefore not only database specialists. The SQLite extension makes Graft relevant to developers working in any language with a native SQLite library, while the core engine is written in Rust. The repository also presents Graft as storage and replication infrastructure for databases, but it does not impose a particular data format or schema on object storage. That makes the design relevant to teams that need synchronization beneath a conventional SQL interface, though the project remains explicitly at Alpha quality.

Graft's transaction and replica architecture

The README describes Graft as transactional object storage. Rather than requiring a particular object layout, it supports consistent changes to subsets of stored data at page granularity. Transactional behavior is based on Serializable Snapshot Isolation, which the project lists as its consistency model. The README does not detail the implementation of conflict detection, transaction logging, or snapshot creation, so those mechanisms should be evaluated in Graft's internals documentation rather than inferred from the feature list.

Graft decouples metadata from data. According to the README, this separation allows a read replica to start immediately without replaying a transaction history or waiting for full recovery. This is a concrete architectural distinction from designs in which a replica must first reconstruct its local state before serving reads. It also explains why the project associates itself with stateless replicas and serverless environments.

Replication remains selective. Updates can affect only the required pages, and clients request synchronization when they need particular data. The intended data path therefore has three broad stages: an application requests required data, Graft identifies and transfers the relevant portion, and transaction rules preserve a consistent view. Those stages come from the project's published claims. The README does not expose the wire protocol, conflict policy, authorization model, object-store requirements, or operational APIs, so implementation evaluation will require more than its summary.

Using the Graft SQLite extension

The first supported route for most new users is the Graft SQLite extension, not direct embedding of the Rust crate. The README sends readers to the extension documentation at https://graft.rs/docs/sqlite/ for download and SQLite setup instructions. No installation command, loadable extension filename, loader configuration, environment variable, or initialization query appears in the README, so this review does not invent one.

Start by opening the SQLite extension documentation and following its current download instructions for the target platform. Then load the extension through the native SQLite integration used by the application. Graft states that this route works from any language with a native SQLite library. The first useful application test should involve two independently created databases, a transaction that changes a small subset of pages, and synchronization of only the data needed by the other database.

For a Rust application, the alternative is direct embedding through the `graft` crate. The README links to https://docs.rs/graft but does not provide a Cargo dependency line, initialization sequence, or code example. Direct embedding is consequently not documented here as a turnkey tutorial. Access to Graft's low-level Volume API from languages other than Rust is also unresolved. The project asks interested developers to file an issue rather than presenting this interface as generally available.

Graft's Alpha and release constraints

The largest limitation is stated by the project itself: Graft should be considered Alpha quality software. The README asks prospective production users to contact `@carlsverre` before using it, with Discord identified as the easiest contact route. This makes Graft an evaluation target rather than a dependency that can be introduced on the same basis as a mature storage component. The label applies even though the repository is not archived and the last push was on 2026-10-13.

Release history is short and concentrated. The listed stable releases are `v0.2.1` on 2025-12-04 and `v0.2.0` on 2025-12-03, preceded by `v0.2.0-rc.7` on the same date. This history suggests an early public release line, but it does not establish upgrade compatibility. The repository does not document a stability policy, schema migration procedure, object-store compatibility matrix, long-term-support release, or production support commitment.

The Rust workspace declares `rust-version = "1.91"`, which gives adopters a minimum Rust version reference. It also includes a broad set of storage, serialization, networking, SQLite, and testing dependencies. Those facts define some build context, but they do not quantify the effort needed to upgrade. Teams should expect to assess breaking changes directly against each release because the README does not promise compatibility across `v0.2.x`.

Graft licensing and repository scope

The README offers licensing under either the Apache License, Version 2.0 or the MIT license, at the user's option. The workspace package metadata expresses the same choice as `MIT OR Apache-2.0`. This is a permissive dual-license arrangement, but this review does not provide legal advice or assess how a particular distribution model interacts with those terms.

The repository is organized as a Rust workspace with packages under `crates`, alongside documentation, tests, tasks, datasets, Docker-related files, and SQLite packaging configuration. The `justfile` exposes a `test` task that runs `cargo nextest run`, `cargo test --doc`, and `just run sqlite test`. These are repository commands rather than user installation instructions, and the truncated `justfile` does not show the full `just run` contract. They nevertheless confirm that the repository contains Rust, SQLite, and integration testing infrastructure rather than a single extension binary.

The public entry point differs by audience. Application developers are directed first to the SQLite extension documentation. Rust developers can inspect the crate docs. The project documentation also points to an internals overview at https://graft.rs/docs/internals for its architecture.

Graft compared with ordinary SQLite distribution

Ordinary SQLite is the clearest alternative when an application only needs a local database file. Graft builds on the SQLite route through its extension, but adds transactional object-storage integration, partial replication, strong consistency, and on-demand synchronization. A standalone SQLite file remains simpler when all clients are local, shared state is coordinated by a single service, or the application has no need to synchronize subsets between peers.

The difference is therefore not that Graft replaces SQLite syntax in every workload. It changes the storage and replication responsibility around SQLite-compatible applications. Graft's claims become relevant when a client must operate through disconnection, a replica needs to become readable without a full recovery replay, or transferring an entire dataset would waste bandwidth. They do not automatically make Graft preferable for a normal single-node application.

Several comparison criteria remain undocumented in the README. Graft does not state which object storage services are officially supported, how schema evolution is handled, how write conflicts are surfaced, or whether the extension is available for every SQLite target and language binding. Those are adoption boundaries, not minor omissions, because they affect deployment and upgrade planning.

Editorial conclusion

Graft suits engineers evaluating page-level synchronization for SQLite applications at edge, mobile, embedded, serverless, or offline-first deployments. It is not a documented production choice for teams unwilling to work with Alpha software and contact its maintainer first. Before adoption, verify the current SQLite setup instructions, confirm that page-granularity replication fits the application data model, and test the exact consistency and failure behavior needed by the deployment.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. orbitinghail/graft on GitHub
3. Project website
4. README
5. Releases