Short answer: no. In Prefect 3.x, “resetting” the server database wipes everything the server knows about, not just history. What a database reset deletes - Deployments (and their schedules, parameters, tags) - Automations (all triggers and actions) - Flows/flow versions metadata - Flow runs, task runs, artifacts, logs, concurrency limits - Work pools and work queues - Blocks (both block types you registered and block documents) - Variables - Any other server-side configuration What is not affected - Your code repositories, Docker images, storage locations, and worker processes on your machines - Anything outside the Prefect database How to reset

prefect server database reset -y

Docs: Server CLI (see “database reset”) How to rebuild after a reset - Deployments - From each project, run

prefect deploy ...

again to (re)create deployments - Or programmatically:

flow.from_source(...).deploy(...)

- Work pools/queues - Recreate pools:

prefect work-pool create "my-pool" --type <process|docker|kubernetes|...>

- Recreate queues if you used them:

prefect work-queue create --work-pool "my-pool" "my-queue"

- Restart workers so they connect to the recreated pool/queue - Blocks - Re-register block types you use:

prefect block register -m your_module_containing_block_types

- Recreate block documents via the UI (or programmatically) - Variables

prefect variable set KEY VALUE

- Automations - There is no

prefect automation create

CLI; recreate via the UI or programmatically with the Python client/automation models - API refs: Automations API, Client API Recommended pre-wipe checklist (even if you don’t care about run history) - Back up the SQLite file first: copy

~/.prefect/prefect.db

- Snapshot your current config so you can recreate it: -

prefect work-pool ls

-

prefect work-queue ls

-

prefect block ls

and

prefect block inspect <name>

-

prefect automation ls

and

prefect automation inspect <id>

-

prefect variable ls

- Ensure each flow project can be redeployed with

prefect deploy

If your goal is to migrate from SQLite to Postgres, treat the Postgres-backed server as a fresh environment and follow the rebuild steps above. There isn’t a supported cross-DB migration tool; redeploying/recreating is the standard path. Want me to generate a concrete rebuild plan/commands based on your current pools/queues/blocks/automations before you reset?