Skip to main content

Design Comparison

This page explains Sync-in's architectural positioning compared with several open source file sharing and synchronization platforms. The goal is not to rank products feature by feature, but to clarify storage and metadata trade-offs that matter for operation, migrations, backups, and long-term data control.

Sync-in Positioning​

Sync-in keeps files in their original filesystem. The platform does not turn the storage area into an opaque application repository, nor does it require a specific object-storage layout for ordinary files.

Collaborative metadata is created only when a feature needs it: sharing, permissions, virtual anchoring, synchronization, comments, activity, collaboration, and related platform state. The database therefore reflects the collaborative use of the platform rather than duplicating the whole file tree by default.

When a file already carrying metadata changes on the filesystem, Sync-in can reconcile the real storage state with the existing metadata. The platform keeps its collaboration features coherent without turning every file into a mandatory entry in a global cache.

Full-text indexing is separate from this metadata model. It concerns document content, can be enabled or disabled, and can rely on specialized search engines for full-text workloads, such as Elasticsearch, instead of adding pressure to the database.

This provides six practical benefits:

  • Readable storage: files remain directly usable by standard system tools.
  • Operational simplicity: backups, snapshots, antivirus scans, and external processes can keep working on normal files.
  • Reduced indexing overhead: large file trees do not automatically imply a large file metadata database.
  • More predictable scalability: database load follows functional usage first, not only the raw number of stored files.
  • Targeted reconciliation: existing metadata can be aligned with the real filesystem state when needed.
  • Reversibility: an installation can be stopped or migrated without first reconstructing user files from a proprietary layout.

Differences with Existing EFSS Architectures​

Nextcloud and ownCloud 10​

Nextcloud and ownCloud 10 keep a file cache that mirrors file state in the database. Nextcloud documents commands such as files:scan, files:cleanup, and files:repair-tree to update or repair that cache, especially after files are copied directly into the data directory or after migrations. ownCloud's migration documentation describes oc_filecache as storing file metadata, including a full replication of the file tree.

This model is powerful for a broad application ecosystem, but it also makes the database a central operational component for file visibility and consistency.

Sources:

OpenCloud and ownCloud Infinite Scale​

OpenCloud and ownCloud Infinite Scale move away from the old PHP server model, but still rely on storage drivers with specific metadata behavior. OpenCloud PosixFS stores additional metadata in extended file attributes and can move larger metadata to a separate metadata file. ownCloud Infinite Scale PosixFS also requires extended attributes and filesystem notifications for shared filesystem access.

These architectures improve some direct filesystem access scenarios, but they still place structural requirements on the underlying filesystem and its metadata capabilities. Their portability therefore depends on preserving these metadata attributes and filesystem requirements during copy, restore, or migration to another instance.

Sources:

Seafile​

Seafile uses an internal model inspired by Git, with repositories, commits, filesystem objects, and content blocks. Files can be chunked into blocks for deduplication and efficient transfer. This design is strong for synchronization efficiency and history management, but the storage is no longer a plain user-visible filesystem tree.

Sync-in takes a different operational trade-off: it favors ordinary filesystem readability and targeted metadata over a specialized object model for every file.

Source:

Syncthing​

Syncthing is primarily a peer-to-peer synchronization system, not a centralized EFSS governance platform. It keeps files on participating devices and tracks versions, block lists, and synchronization state in a local index database. It also relies on filesystem watchers and periodic scans to detect changes.

This makes Syncthing excellent for decentralized synchronization, but it does not provide the same server-side collaboration model as Sync-in: managed spaces, nested sharing, delegated permissions, WebDAV access, audit, and centralized administration.

Source:

What Differentiates Sync-in​

Sync-in's strongest differentiation is not just that files are stored on disk. The more precise point is that Sync-in keeps the filesystem as the primary storage reality, creates platform metadata only where collaboration requires it, and can reconcile that metadata with the real storage state.

This leads to a pragmatic EFSS model:

  • No opaque repository for ordinary files: the data remains readable outside the application.
  • No full file-tree mirror by default: database growth follows functional usage rather than raw file count.
  • Usage-oriented scalability: the platform can host very large file trees without converting every file into persistent application state.
  • State reconciliation: files already associated with metadata can be realigned with the filesystem without scanning the whole tree as a permanent application source of truth.
  • No mandatory backend-specific layout: storage can remain close to existing filesystem practices.
  • Collaboration without duplication: virtual anchoring exposes content in spaces without copying it.
  • Clear governance: managers, shares, permissions, and activity remain platform-managed without absorbing the storage itself.

For administrators, the result is a lighter operational model: fewer global rescans tied to the consistency of a full file cache, less database pressure on very large trees, simpler backup and restore workflows, and lower coupling between the application and the physical storage layout.