Scheduled tasks

Run built-in dumps, native backups, and saved-query exports on a schedule while SQLly is open.

SQLly can run three kinds of task hourly, daily, or weekly: a built-in SQL dump, a native backup with pg_dump or mysqldump, or a query export that runs a saved query from the SQL library and writes the result to a CSV or JSON Lines file. To add one, run Schedule Task (Dump, Backup, or Query Export)… from the command palette, or click Add… in Settings ▸ Workspace ▸ Scheduled dumps. Pick the database and the task, then set the output folder, cadence, and how many files to keep.

Every task writes into an output folder, never a single file: each run adds a new timestamped file there, and the first run creates the folder if it doesn't exist. Choose… opens a folder picker. The default is a SQLLY Backups folder in your home folder.

SQLly

Runs only while SQLly is open

SQLly checks for due tasks once a minute, and only while the app is running. It does not install a cron job, a launchd agent, or a Windows scheduled task. If a run was due while SQLly was closed, it runs at the first check after you open the app again. When you need a task to run with SQLly closed, use Copy CLI command (below) and paste the line into cron (on Windows, a Git Bash or WSL cron job).

Keeping the newest files

Keep sets how many of a task's files stay in its folder (0 keeps them all). After each complete run, older files are deleted. A cancelled or failed run deletes nothing. In the names above, <id> is a short id unique to the task and <stamp> is YYYYMMDD-HHMMSS. Pruning only deletes names of exactly that shape for that task, so other tasks, other connections with a database of the same name, and your own files in the folder are never touched. A folder is deleted only when it holds nothing but a one-file-per-object dump. Files named by earlier versions of SQLly, without the task id, are left in place.

Safety rules

• Query exports are read-only. The saved query must be a single read-only SELECT. It runs on a connection locked to SELECT, with the database's own read-only mode turned on too. Any other statement, or a query that returns more than one result set, makes the run fail, and the reason is recorded. The query is read from the SQL library folder set in Settings, so moving the library doesn't break the task.
• Production connections never run. Scheduled tasks, including Run now, skip connections marked as production. The skip is recorded as the task's last result.
• Native backups need a direct connection. pg_dump and mysqldump connect to the database themselves, so a connection reached through a relay bridge records an error instead of running.
• Missing pieces are reported, not guessed. If pg_dump or mysqldump isn't installed, the run records the error and tries again at the next slot. Set the tool's path in Settings ▸ Advanced ▸ Database tools. If the saved query was deleted, or the connection no longer exists, the task turns itself off and says why.
• No passwords in the file. dump-schedules.json stores the connection's id, never its credentials. Native tools get the password the same way as a manual native dump.
• A damaged task file is kept. If dump-schedules.json can't be read, the Scheduled dumps pane shows the error and SQLly refuses to save over the file until you fix or move it. The pane reads the file again each time you open it, so a fix shows up when you come back to it.

Managing tasks

Settings ▸ Workspace ▸ Scheduled dumps lists every task with its connection, database, task, cadence, how many files it keeps, the next run, and the last result. Each row has Run now, Edit… (reopens it in the schedule editor), Copy CLI command, and Remove. Run now tells you in the status bar when a task is already running. Tasks saved before task types existed load as built-in SQL dumps.

Scheduled tasks need the desktop app. The browser version can't write files on a schedule.