Files and media

Lix stores text and binary files in lix_file. This includes images, audio, video, archives, and application-specific formats.

You use normal file paths and bytes. Lix handles the storage details.

Write a file

Write file content with SQL. In JavaScript:

await lix.execute("INSERT INTO lix_file (path, content) VALUES ($1, $2)", [
  "/media/intro.wav",
  audioBytes,
]);

In Rust, use the same SQL model:

lix.execute(
    "INSERT INTO lix_file (path, content) VALUES ($1, $2)",
    &[
        lix::Value::Text("/media/intro.wav".to_owned()),
        lix::Value::Blob(audio_bytes.into()),
    ],
)
.await?;

Verify file content

Compute a SHA-256 checksum of the exact stored bytes without downloading the file. Bind $1 to its absolute path:

SELECT encode(sha256(content), 'hex') AS content_sha256
FROM lix_file
WHERE path = $1;

Compare the returned lowercase hexadecimal checksum with sha256sum file on Linux or shasum -a 256 file on macOS. This works for text and arbitrary binary files; do not cast content to text before hashing.

The checksum is computed on demand and reads the complete file, so its cost grows with file size. It is not a stored column or Lix's internal chunk-store identity. See SQL Functions for hashing and encoding functions.

How large files are stored

Lix stores file bytes in a content-addressed store. Lix splits large files into chunks. It stores equal chunks once, even when they appear in several files or branches.

The chunk store gives Lix three properties:

• integrity checks on stored content;
• chunk-level deduplication;
• garbage collection when content is no longer reachable.

Applications never call the chunk store or the server's transfer protocol directly. Read and write lix_file with SQL.

What belongs in the repository

Store source files in Lix, along with the metadata needed to understand them. Derived data such as thumbnails, waveform caches, and temporary render files can stay outside the repository when your application can rebuild them.

Storage

Binary content uses the repository's selected storage adapter. Use RocksDB or the local filesystem for native applications. Use SlateDB with S3-compatible object storage for hosted repositories. See Storage.