Introducing Persist — Local-First Storage for the Modern Stack

We have been building applications on top of cloud databases for over a decade. The model works, but it comes with trade-offs that compound over time: every read hits the network, every write depends on server availability, and your users’ data lives on someone else’s infrastructure. Persist is our answer to this.

What is Persist?

Persist is a local-first storage SDK. It writes data to a local database on the device first, then syncs to other devices and servers in the background. Your application code does not change when the network is down. Reads are instant because they never leave the machine. Writes are durable because they go to local disk before anything else.

The API is intentionally small. You create a store, then interact with four sub-stores: records (key-value documents), events (append-only logs), blobs (binary objects), and kv (simple key-value). The shape of your data determines which class you use, not the underlying storage engine.

Why local-first?

Cloud-first architectures tie your application’s responsiveness to network conditions. A database outage on the other side of the world should not block a user from editing a document on their laptop. Local-first inverts the dependency: the network is used for replication, not as a prerequisite for function.

This matters especially for applications that operate in intermittent connectivity — field tools, mobile apps, collaborative editors, IoT devices. But it also matters for traditional web applications that want faster reads and better resilience.

Pluggable adapters

Persist separates the storage API from the storage engine. Four built-in adapters cover the most common scenarios:

SQLite — zero-config embedded storage. The default for local-first apps.
Postgres — for server-side workloads, full-text search, and relational queries.
S3 — handles large binary objects. Works with AWS S3, Cloudflare R2, and MinIO.
P2P — direct device-to-device replication over libp2p with no central server.

Swapping adapters requires only a configuration change. Your application code stays the same.

Sync and encryption

The sync engine queues writes locally and pushes them to configured remotes when connectivity is available. Conflict resolution supports last-write-wins, custom merge functions, and manual resolution. The sync planner batches operations, deduplicates redundant writes, and compresses payloads.

Every sync payload can be signed with Ed25519 keys. Envelope encryption protects data at rest with AES-256-GCM, and key rotation is atomic — no downtime, no re-encryption of existing records.

Part of the Cuitty ecosystem

Persist is a standalone SDK, but it is designed to work within the broader Cuitty platform. Cuitty modules for audit, configs, deploys, and secrets can use Persist as their storage layer. The admin portal surfaces Persist metrics — store sizes, sync status, conflict counts — alongside other operational data.

If you use Cuitty for infrastructure management, Persist gives you a consistent storage model across modules. If you use Persist on its own, it has no dependency on the rest of the platform.

Getting started

Install the SDK and create your first store in under five minutes:

npm install @cuitty/persist

import { createStore } from "@cuitty/persist";

const store = await createStore("my-app", {
  adapter: "sqlite",
  path: "./data/my-app.db",
});

await store.records.put("hello", { message: "world" });
const record = await store.records.get("hello");
console.log(record.value.message); // "world"

Read the quickstart guide for the full walkthrough, or explore the concepts to understand the architecture. SDKs are available for TypeScript and Python, with a CLI for scripting and automation.

We are shipping this as v0.1.0. The core API is stable, adapters are tested, and sync works. We will be iterating on performance, adding new adapters, and expanding the SDK surface based on feedback. If you build something with Persist, we would love to hear about it.