Your jobs remember where they left off
Every saved package gets its own storage: a key/value store for cursors, caches and checkpoints, and a SQLite database for tables you can filter, join and index. Nothing to provision, and nothing another package can reach.
Two kinds of state, one package
Use whichever fits. Most packages start with a few keys and add tables later.
Cursors and checkpoints
The key/value store keeps small JSON values: the last issue a job saw, the page a sync stopped on, a cached response. The next run reads it and carries on.
Tables when you need them
Each package has a SQLite database of its own. Create tables, add indexes, upsert rows and query them with joins.
Set up by your agent
Ask for a job that tracks something over time and your agent adds the storage as it writes the package. You never create a database or paste a connection string.
Kept apart, and kept clean
One database per package
Other packages, apps and organizations can't reach it. Delete the package and its data goes with it.
Every statement is a transaction
A statement that fails or hits a limit is rolled back, so a half-finished write never sticks.
Yours to export
Export a package's stored keys as JSON, or everything your organization holds, whenever you want.
Where job state usually lives
Questions about storage
Is it Postgres?
No, it's SQLite. Most SQL moves over with small edits: timestamps are ISO text, booleans are 0 and 1, and JSON lives in text columns you read with json_extract. The packages docs cover the details.
Are there limits?
Each statement gets 5 seconds and returns up to 1,000 rows, and the database's size counts against your plan's storage limit.
Can my agent look at the data?
Yes. Any connected agent can read and write a package's keys, or run a query against its database, through Minion.
Build a job that picks up where it stopped
Connect your agent and ask for something that runs every morning and remembers yesterday.