> ## Documentation Index
> Fetch the complete documentation index at: https://superdoc-caio-sd-2792-selection-active-ids.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Storage

SuperDoc is a self-hosted solution where you decide how and when documents are stored. Existing storage solutions like S3 and Cloud Storage are secure and work well.

## Storage approaches

How and when a document is stored often depends on the level of document collaboration needed.

| Collaboration Level         | Approach     | Complexity | When Changes Are Stored   |
| --------------------------- | ------------ | ---------- | ------------------------- |
| [High](#high-collaboration) | Yjs/CRDT     | Medium     | Continuously (backend)    |
| [Low](#low-collaboration)   | Check in/out | Low        | User-triggered (frontend) |

### High collaboration

For real-time, multi-user collaboration (similar to Google Docs) using Yjs/CRDT, each client connects to a [realtime collaboration service](/modules/collaboration/overview) that merges all user updates.

<Info>
  **Complexity: Medium** — Requires a server-side [Yjs/CRDT service](/guides/collaboration/self-hosted-overview)
</Info>

**How it works:**

* Every document edit (as a Yjs byte array) is automatically sent via WebSocket to the Yjs/CRDT service
* When all changes are merged, the service stores the new document
* Storage happens continuously on the backend

### Low collaboration

For scenarios where only one user edits at a time (like SharePoint), implement a locking mechanism where users check out documents before editing.

<Info>
  **Complexity: Low** — Requires storing and querying document lock/unlock state
</Info>

**How it works:**

* When the active user [makes an edit](/core/supereditor/events#onupdate), debounced changes are sent to your server which stores the document
* Alternatively, when a user saves/checks in the document, it is sent to your server for storage
* Storage is triggered by user actions on the frontend

## What to store

In both [low collaboration](#low-collaboration) and [high collaboration](#high-collaboration) approaches, when the document arrives at your backend:

<Steps>
  <Step title="Create a unique version ID">
    Generate a unique identifier for the document version:

    ```
    document_revision1764976265.docx
    ```
  </Step>

  <Step title="Store the document version">
    Save the full DOCX binary to your cloud storage:

    ```
    s3://documents_bucket/versions/document_revision1764976265.docx
    ```
  </Step>

  <Step title="Save version metadata">
    Store the document version ID and its storage path in your database for later retrieval.
  </Step>
</Steps>

When the document is requested later, look up the latest version in your database and serve it from cloud storage.

## Export methods

The ways to export a document are covered in [Import/Export](/getting-started/import-export#export-options).

<Note>
  Store the [full DOCX binary](/getting-started/import-export#docx-export-full-fidelity) for the highest fidelity version of the document.
</Note>

## Best practices

<CardGroup cols={2}>
  <Card title="Unique Version IDs" icon="fingerprint">
    Include timestamps or UUIDs to ensure uniqueness
  </Card>

  <Card title="Store Full DOCX" icon="file">
    Preserves all formatting, comments, and tracked changes
  </Card>

  <Card title="Keep Version History" icon="clock">
    Store multiple versions for audit trails and recovery
  </Card>

  <Card title="Use Cloud Storage" icon="cloud">
    S3, Google Cloud Storage, or Azure Blob Storage
  </Card>
</CardGroup>