# Classic Jazz: the syncing database that runs in your frontend, containers and serverless functions

> Classic Jazz is the pre-v2 branch of the Jazz local-first database from Garden Computing. It syncs JSON-like state between browsers, servers and a storage cloud, and its own README now points new projects at Jazz v2 instead.

**garden-co/classic-jazz** — A new kind of database that's distributed across your frontend, containers, serverless functions and its own storage cloud.

- Repository: https://github.com/garden-co/classic-jazz
- Website: https://classic.jazz.tools
- Stars: 2,534 · Forks: 111
- Language: TypeScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/garden-co-classic-jazz

## What Classic Jazz solves, and who the README says should use it

Most applications end up maintaining two copies of the same state: one in the browser for responsiveness, one in a database for durability. Keeping them in agreement is where the bugs live. Classic Jazz removes that split by treating the client as the primary holder of the data and syncing changes outward. The README describes it as "a new kind of distributed database that runs across your frontend, containers, serverless functions and its own cloud", and says it "syncs data, files and LLM streams instantly and feels like reactive local JSON state". The repository topics list the same concerns: crdt, end-to-end-encryption, local-first, offline-first, reactive, state-management, sync.

The audience is narrower than the description suggests. This is the Classic Jazz repository, and the README opens with a warning that the maintainers "recommend using Jazz v2 for new projects", linking to the newer repository, the jazz.tools homepage, and a blog post titled "what we learned from classic jazz". That single line changes the adoption decision more than any feature list. Classic Jazz is for teams already running it, or teams that need the v1 API and are willing to pin. It is not the branch a new project should start on.

## How the sync mechanism is laid out in the repository

The monorepo separates the sync engine from the application-facing layer. The core is written in Rust: crates/ sits at the top level, and the package.json workspaces list includes crates/* and crates/cojson-core-napi/npm/*, so the core is compiled to native Node bindings and, judging by the build scripts, to WebAssembly as well. The scripts build:core runs build:napi, build:rn and build:wasm in sequence, which means the same engine targets Node, React Native and the browser.

Above that sits the TypeScript layer. The published packages visible in the release list are jazz-tools, jazz-run and jazz-webhook, all at version 0.20.19. jazz-tools is the client library an application imports; jazz-run is the command line tool used to run a local sync server; jazz-webhook handles outbound notifications. The devDependencies in the root package.json reference jazz-tools and jazz-run as workspace packages, which is how the examples and tests consume them.

The runtime model is a sync server that clients connect to. Data is held locally and changes propagate to the server and to other connected clients. Because the engine is a CRDT implementation, concurrent edits from two clients converge without a coordinator deciding who wins. End-to-end encryption is listed as a built-in, which is why the server can relay data it cannot read. The repository also carries an examples/inspector directory, so there is a tool for looking at what the sync layer is doing. The README does not describe the wire protocol, the conflict resolution rules, or how encryption keys are exchanged; for those you are expected to read classic.jazz.tools/docs.

## Installing Classic Jazz and getting a first sync running

The README does not contain install commands. It points to the homepage and docs for an overview, and the practical starting point in the repository is the examples/ and starters/ directories. The root package.json pins the toolchain: packageManager is pnpm@10.16.1 and engines requires node >=22.18.0. That Node floor is worth checking before anything else, because the native core build will not run on older runtimes.

Clone the repository and install with pnpm. The workspace covers packages, examples, starters and the Rust crates, so a single install pulls the whole tree:

```bash
pnpm install
```

The root scripts build the core first and then the packages. build:core runs the Rust targets, and build:packages filters to packages/*. Running them in the wrong order will leave the TypeScript packages looking for bindings that do not exist yet:

```bash
pnpm build:core
pnpm build:packages
```

To run a sync server locally, the repository ships jazz-run as a workspace package. The README does not document its flags, so treat the command below as the entry point and check the package for the arguments it accepts:

```bash
pnpm jazz-run
```

For an application, the import surface is jazz-tools. The examples in the repository (examples/chat, examples/jazz-nextjs, examples/jazz-sveltekit and others) are the reference for how a provider is wired into a framework. The README does not show that wiring inline, so read an example before writing your own.

## Where Classic Jazz stops being the right tool

The first limitation is stated by the project itself. The README recommends Jazz v2 for new projects and links to a post about what was learned from this version. That is an unusually direct signal, and it means the default answer for a new codebase is no. The repository is not archived and the last push was on 2026-09-07, so work is still landing, but the direction of that work is maintenance rather than a new feature surface.

The second limitation is the documentation gap around migration. The README does not document a path from Classic Jazz to Jazz v2. There is no upgrade guide, no compatibility statement, and no note on whether schemas or stored data carry over. If you build on Classic Jazz now, you are accepting that the exit is undefined until the linked blog post or the v2 repository says otherwise.

The third is operational. A syncing database needs a server the clients can reach and hold open. Serverless functions are named in the README as a supported host, but the sync connection itself is long-lived by nature, which is a poor fit for platforms that cap execution time. The README does not address this, and the examples/durable-object directory suggests that at least one deployment model depends on a platform primitive rather than a plain function. If your runtime cannot hold a connection, the client falls back to local-only behaviour, which is functional but not what you adopted the project for.

## Classic Jazz against a plain client plus REST backend

The honest alternative is not another local-first database. It is the architecture most teams already have: a REST or GraphQL API, a database behind it, and a client-side cache such as a query library. The difference is where authority lives. In the conventional stack, the server owns the record and the client asks for it; conflicts are resolved by whichever request arrives last, and offline writes are either queued explicitly or rejected. In Classic Jazz, the client owns a replica, edits are CRDT operations, and the server is a relay and a store rather than a gatekeeper. Offline edits merge when the connection returns instead of being replayed as a sequence of requests.

That trade is real in both directions. The conventional stack gives you a single place to enforce authorization, which is easy to reason about and easy to audit. Classic Jazz moves permissions into the data model and encrypts payloads end to end, so the server cannot inspect what it stores. That is the point of the design, and it is also why server-side validation of content is not something you can bolt on afterward. If your product needs to scan, index or moderate user content centrally, the encryption model works against you, and a conventional backend is the better fit. If your product needs two people editing the same document on a flaky connection, the conventional stack is where the reconciliation code gets written by hand.

## Maintenance, licensing and what an upgrade costs

Classic Jazz is MIT licensed, and the LICENSE.txt file sits at the repository root alongside the README. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the extent of what the repository states; it says nothing about trademarks, hosted service terms, or what the Jazz Cloud offering requires, and none of that is legal advice.

The maintenance picture is mixed and worth reading carefully. The repository is not archived and the last push was on 2026-09-07, so the code is current. The most recent releases listed are jazz-tools, jazz-run and jazz-webhook at 0.20.19, all published on 2026-07-03, which is roughly two months before the last commit. The project uses Changesets, with a .changeset/ directory and a changeset script in the root package.json, so version bumps are a deliberate, reviewable step rather than an accident of merging. For a consumer, that means upgrades arrive as explicit package versions you choose to take.

The upgrade cost is where the risk sits. The README points to Jazz v2 and to a blog post explaining the differences, but it does not describe an in-place upgrade from this branch. A team on Classic Jazz should treat the version pin as load-bearing: the root package.json uses a catalog for several dependencies and workspace references for the internal packages, which is fine inside the monorepo but not a pattern you can copy into an application. In your own project you will be depending on published jazz-tools versions, and the repository does not state how long those will keep being published.

## Conclusion

Adopt Classic Jazz when you are maintaining an existing Classic Jazz application, or when you specifically need the v1 API surface and are prepared to pin versions, because the README itself recommends Jazz v2 for new projects. Do not adopt it for greenfield work, and do not adopt it if you need a documented migration path, since the README does not document one. Before you commit, install jazz-tools and jazz-run at the published 0.20.19 versions, run the sync server locally, and verify that your deployment target can hold a WebSocket connection open for the lifetime of a session. If that check fails, Classic Jazz is the wrong tool regardless of how well the rest of the API fits.

## FAQ

### What is Classic Jazz?

It is a distributed database from Garden Computing that syncs data, files and LLM streams across frontends, containers, serverless functions and its own cloud, and presents itself as reactive local JSON state. It is the pre-v2 branch of Jazz, and the README recommends Jazz v2 for new projects.

### Is Classic Jazz still maintained?

The repository is not archived and the last push was on 2026-09-07, while the newest releases listed are jazz-tools, jazz-run and jazz-webhook at 0.20.19 from 2026-07-03. The README nonetheless directs new projects to Jazz v2.

### How do I install Classic Jazz?

The README does not give install steps and instead points to classic.jazz.tools and its docs. From the repository, installation is a pnpm workspace install requiring node >=22.18.0 and pnpm@10.16.1, followed by pnpm build:core and pnpm build:packages.

### What licence does Classic Jazz use?

It is MIT licensed, with LICENSE.txt at the repository root. The repository does not state terms for the hosted Jazz Cloud service.

### Can I self-host Classic Jazz?

The README says you can self-host or use Jazz Cloud. The jazz-run package is the command line tool for running a sync server, though the README does not document its flags.

## Sources

- [garden-co/classic-jazz on GitHub](https://github.com/garden-co/classic-jazz)
- [License: MIT](https://github.com/garden-co/classic-jazz/blob/main/LICENSE)
- [Project website](https://classic.jazz.tools)
- [README](https://github.com/garden-co/classic-jazz/blob/main/README.md)
- [Releases](https://github.com/garden-co/classic-jazz/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/garden-co-classic-jazz