Choose from deployment requirements
| Database | Use it when | Do not overlook |
|---|---|---|
| SQLite | Local evaluation or a single-process deployment. | Persist and back up the database file; do not mount one file writable from several Daptin instances. |
| PostgreSQL | Multi-user production, independently operated persistence, or multiple application instances. | Require transport security where the network is untrusted and reserve connections for administration and recovery. |
| MySQL | Your team already operates a compatible MySQL service and has tested the Daptin release against it. | Verify server/version compatibility and schema initialization in a disposable database first. |
Supply the connection at startup
# SQLite file
./daptin -db_type=sqlite3 \
-db_connection_string=/var/lib/daptin/daptin.db
# PostgreSQL
./daptin -db_type=postgres \
-db_connection_string='host=db.example port=5432 user=daptin password=secret dbname=daptin sslmode=require'
# MySQL
./daptin -db_type=mysql \
-db_connection_string='daptin:secret@tcp(db.example:3306)/daptin'
The default environment-variable name for the connection string is
DAPTIN_DB_CONNECTION_STRING; the
-database_url_variable flag can name a different
variable. Keep credentials in the deployment secret mechanism,
not in source control or a container image.
Verify persistence, not only connectivity
- Start Daptin against a new disposable database and inspect startup for connection or schema errors.
- Request
/ping, then create and read a disposable application record. - Restart Daptin with the same connection settings and read the record again.
- Run the database’s native backup, restore into a separate database, and start a disposable Daptin instance against the restore.
- Confirm that a invalid password or unreachable host fails clearly and does not silently create a different local database.
Bound the connection pool
Daptin configures maximum open and idle connections plus connection and idle lifetimes. Size the open-connection budget across every Daptin instance, leave capacity for migrations and operator access, and test with representative concurrency. A copied value is not a capacity plan. Watch database wait statistics and application latency while increasing load.
Prepare the production database
Use a dedicated least-privilege database account, restrict network access, enable database TLS when traffic crosses an untrusted network, monitor capacity and connection exhaustion, and define upgrade and rollback before changing Daptin or the database. Then continue to Production deployment.