Sync Engines Are the Future

Original Article ↗ Hacker News Discussion ↗

Security, Servers, and “Database-as-API”

  • Several commenters argue directly exposing a database to clients is inherently risky; traditional practice is to hide it behind an app server that enforces permissions and business rules.
  • Sync/hosted-DB systems (Firebase-style) are seen as powerful but difficult to secure correctly; access-control rules are complex and error-prone.
  • Enterprise and high‑security use cases especially struggle with row‑level permissions, revocation, and ensuring cached offline data remains authorized.

Network Unreliability and Layering

  • The essay’s “decoupled from an unreliable network” line draws pushback: there is no reliable network; sync just changes where you pay the complexity.
  • Some see “sync engines” as a rebranding of familiar patterns (caching, local DBs, offline queues) rather than a radical shift.
  • Others say big shifts come from moving boundaries, not collapsing layers; there will still be servers, just less app logic on them.

Business Logic in the Database vs in the App

  • A recurring theme: if the DB is “the app,” where does business logic live?
  • Stored procedures / triggers / PL/SQL are cited as ways to keep logic near data, but people complain about testing, version control, lock‑in, and duplicated logic when some checks must also run in clients or other services.
  • Some advocate treating the RDBMS as an application framework with a thin UI; others call that an antipattern for anything non‑trivial.

Conflict Resolution and Local‑First

  • Many see conflict resolution as the central unsolved problem of sync and local‑first, and note the article barely addresses it.
  • Opinions diverge:
    • Some say conflicts are fundamentally domain‑specific and can never be “solved” by infrastructure; you pick strategies (LWW, custom merge) and accept rare anomalies.
    • Others point to CRDTs and transactional reconciliation schemes, but even proponents admit they only handle syntactic conflicts; semantic conflicts still need user or app‑level decisions.
  • Offline writes are where things get truly hard; several products intentionally avoid them or push resolution back to users/UX.

Scope and Limits of Sync Engines

  • Strong enthusiasm for sync in editor‑like, data‑ownership, or mobile/desktop scenarios: no spinners, offline support, optimistic UIs, “local-first” feel.
  • Skeptics argue there is no one general sync engine that works well at all scales and domains:
    • Large datasets (recommendation systems, logistics, airline booking) are poor fits for full local replication.
    • Enterprise apps need complex permissions, auditing, and server‑side side‑effects (emails, third‑party APIs) that don’t map cleanly to “database on the client.”
  • A common compromise: treat local data as a smart cache, sync subsets, and still use traditional APIs for writes or heavy queries.

Prior Art and Tooling

  • Commenters note this space is not new: CouchDB/PouchDB, Meteor, Lotus Notes, Dropbox‑style sync, custom engines in commercial products, and Oracle features like JSON “duality views” plus change notifications.
  • A long list of modern tools is mentioned (Zero, ElectricSQL, PowerSync, Triplit, Convex, Logux, RxDB, etc.), with the observation that everyone is reinventing sync slightly differently.
  • Several practitioners who built bespoke sync systems warn that naïve implementations quickly explode in complexity and become hard to maintain.

UX, Semantics, and “Magic” Layers

  • Sync isn’t just a data problem; it’s also UI and product design: when should live updates move the page under the user vs. show a “new data available” indicator?
  • Some prefer explicit API calls and SSE/WebSockets because “magic” sync layers are harder to reason about and debug.
  • Overall sentiment: sync engines are promising and increasingly important, but not a universal future; they’re another powerful tool with sharp edges.