Database setup

Tether supports MariaDB (recommended), PostgreSQL, and SQLite. All three ship with their drivers pre-installed in requirements.txt — no extra installation needed.

Which database should I use?

DatabaseRecommended forNotes
MariaDB 10.6–11.xProduction (default)Same database Snipe-IT uses — familiar to most MSPs. Included automatically in Docker. Best performance and compatibility.
MySQL 8.0+Existing MySQL infrastructureWorks identically to MariaDB via the same pymysql driver.
AWS Aurora (MySQL-compat)AWS deploymentsFully compatible — uses the pymysql driver. Specify as a full DATABASE_URL.
PostgreSQL 14+Enterprise or existing Postgres infrastructureStrong choice for AWS RDS or organisations standardised on Postgres.
SQLiteDevelopment or single-user evalZero setup. Not recommended for production — concurrent writes are serialised.

MariaDB setup

With Docker (automatic)

If you use Docker Compose, MariaDB starts automatically. No setup required — the credentials from your .env are passed to the MariaDB container on first start and the database is created automatically.

MariaDB is not exposed outside Docker

The db container's port 3306 is only accessible to the app container via the internal Docker network. It is not reachable from the internet.

With bare-metal

bash
sudo apt install -y mariadb-server # Secure the install (set root password, remove anonymous users, etc.) sudo mysql_secure_installation # Create the database sudo mysql -e "CREATE DATABASE tether CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" # Create the user and grant access sudo mysql -e "CREATE USER 'tether'@'localhost' IDENTIFIED BY 'yourpassword';" sudo mysql -e "GRANT ALL PRIVILEGES ON tether.* TO 'tether'@'localhost'; FLUSH PRIVILEGES;" # Verify sudo mysql -u tether -pyourpassword -e "SHOW DATABASES;"

Add to your .env:

bash
DB_HOST=localhost DB_PORT=3306 DB_NAME=tether DB_USER=tether DB_PASSWORD=yourpassword

Tether automatically builds the connection string as:

text
mysql+pymysql://tether:yourpassword@localhost:3306/tether?charset=utf8mb4

PostgreSQL setup

bash
sudo apt install -y postgresql postgresql-contrib # Create the database and user sudo -u postgres psql -c "CREATE DATABASE tether;" sudo -u postgres psql -c "CREATE USER tether WITH PASSWORD 'yourpassword';" sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE tether TO tether;" sudo -u postgres psql -c "ALTER DATABASE tether OWNER TO tether;"

Add to your .env:

bash
DATABASE_URL=postgresql://tether:yourpassword@localhost:5432/tether
psycopg2-binary is pre-installed

The PostgreSQL driver is included in requirements.txt. You do not need to install anything extra — unlike some frameworks, Tether bundles the binary wheel so no system-level libpq headers are needed.

AWS Aurora (MySQL-compatible)

bash
DATABASE_URL=mysql+pymysql://tether:password@your-cluster.cluster-xxxx.us-east-1.rds.amazonaws.com:3306/tether?charset=utf8mb4

Aurora MySQL-compatible mode uses the same pymysql driver as MariaDB — no changes to Tether code needed.

SQLite (development only)

If neither DATABASE_URL nor DB_HOST/DB_USER are set, Tether falls back to SQLite. The database file is created at:

text
$TETHER_DATA/tether.db # e.g. ./data/tether.db
SQLite is not suitable for production

SQLite serialises all writes. With multiple MSP technicians actively checking assets in and out simultaneously, you will see noticeable slowdowns. Use MariaDB or PostgreSQL for any real deployment.

Connection priority

Tether resolves the database URL in this order:

  1. DATABASE_URL environment variable — always used if set, overrides everything
  2. DB_HOST + DB_USER set — builds a MariaDB URL automatically
  3. Neither set — SQLite file at TETHER_DATA/tether.db

Schema management

Tether uses SQLAlchemy's create_all() on startup, which creates any missing tables or columns automatically. You do not need to run migration scripts for additive changes (new tables, new nullable columns with defaults).

For destructive changes (dropping columns, renaming tables), the release notes will include explicit SQL to run before starting the new version. These are rare and always clearly documented.

Check the release notes before upgrading

Always read the GitHub release notes before running an upgrade. Most upgrades are safe to run directly, but some major releases include manual schema steps.

Backing up the database

See Backup & restore for complete instructions including automated cron jobs and offsite storage recommendations.

Last updated: May 2026