Show HN: Triplit – Open-source syncing database that runs on server and client

Original Article ↗ Hacker News Discussion ↗

An open-source project called Triplit aims to simplify building “local‑first” web and mobile apps by running the same syncing database on both client and server, with TypeScript-first tooling and real-time subscriptions. Commenters probe how it handles conflicts, schema evolution, and access control, compare it to alternatives like ElectricSQL, Supabase, RxDB, and Evolu, and note current gaps such as limited aggregation queries, lack of Postgres/Mongo integration, and incomplete collaborative text support. A major thread centers on its AGPL licensing—especially for frontend libraries—which some see as protecting community contributions but others view as a barrier to commercial adoption.

Overview & Use Cases

  • Triplit is an open-source, syncing database that runs on both server and client with strong TypeScript, React, Svelte, and React Native support; Vue bindings are planned.
  • Targeted primarily at web developers and “classic” client–server apps with a central authoritative server rather than fully decentralized peers.
  • Reported real-world use includes offline-capable apps, user settings syncing across devices, and React Native apps; some users plan to move more critical data once HA deployments are available.

Sync Model & Conflict Resolution

  • Uses last-writer-wins (LWW) registers per attribute. Concurrent edits result in one winning; the other is still in history but not visible.
  • This is considered fine for simple fields (e.g., checkboxes), but not for collaborative text; richer collaborative editing via sequence/CRDT libraries is on the roadmap.

Architecture & Integrations

  • Server currently uses SQLite by default, with adapters also existing for LevelDB, LMDB, and file storage.
  • Not yet usable directly with existing Postgres or MongoDB; an internal Postgres sync tool (via replication/WAL2JSON) exists but isn’t production-ready.
  • Access control is defined via schema rules; a more granular system (separate read/insert/update/delete hooks) is in progress.

Performance, Latency & Schema Evolution

  • Sync latency is described as “fast enough” for most use cases but not tuned for sub-second cursor/metadata updates; a dedicated “presence API” is planned.
  • Query engine currently lacks aggregations (e.g., COUNT/UNIQUE); incremental/continuous aggregation is planned.
  • Schema evolution guidance: maintain backward-compatible schemas; tooling warns on breaking changes. Longer-term, lens-based migration approaches (Cambria-style) are being explored.

Comparisons to Other Tools

  • Positioned as a more batteries-included, relational-query alternative to tools like RxDB.
  • Other local-first / Postgres-centric solutions mentioned: ElectricSQL, PowerSync, Ably LiveSync, Evolu; Triplit differentiates by avoiding SQL and focusing on a language-level TS experience.
  • Comparisons are also drawn to Meteor’s pub/sub and optimistic UI model; some see Triplit as spiritually similar but more database-focused.

Licensing Debate (AGPL)

  • Triplit (including client libraries and bindings) is licensed under AGPL to keep it self-hostable and encourage contributions of modifications.
  • Extensive debate centers on AGPL’s “viral” nature: several commenters argue that using the AGPL frontend libraries would require entire frontends to be AGPL-compatible, making it unattractive for commercial products.
  • Others argue the legal boundaries (linking, derivative works) are ambiguous and thus risky; some suggest weaker copyleft (e.g., MPL) for client libraries.
  • The maintainers acknowledge confusion and intend to clarify their intent, but no concrete license change is stated.