SQLite Setup Guide

Why SQLite?

Unlike MySQL or PostgreSQL, SQLite does not require a separate Docker container. It runs entirely inside the main monolithic nLink container, reading and writing to a single database file on disk. This drastically reduces server memory overhead.

Docker Compose Modification

SQLite is the default database engine out-of-the-box. The only necessary step is ensuring you expose a persistent volume on the nlink service so your database file survives container updates.

services:
  nlink:
    container_name: nlink-workflow
    image: nlinkio/nlink-workflow:v1.0.0-beta
    ports:
      - "80:80"
    restart: always
    volumes:
      # Map the internal storage directory to your host to persist the SQLite file
      - ./nlink_data:/app/storage
    environment:
      - DATABASE_DEFAULT=SQLITE
      - SQLITE_DATABASE=/app/storage/database.sqlite

Configuration Attributes

• File Persistence: ./nlink_data:/app/storage
  (By mapping the data directory, your SQLite database file e.g. database.sqlite is kept safely on your physical host machine).
• Auto-provisioning:
  (If the system cannot detect a valid `MYSQL_HOST` or `POSTGRES_HOST`, it will automatically spawn the SQLite file inside its working directory and run migrations on boot).

When to avoid SQLite

While incredibly fast for reads, SQLite handles heavy concurrent writes poorly compared to dedicated databases. If you plan to run thousands of workflow executions per minute across multiple sub-flows natively, it is highly recommended to switch back to PostgreSQL.