Rider SQL console scripts excluded from IDE settings backup

The short answer

Rider's settings export does not reliably include SQL console scripts. The dependable mechanism is file-level backup: console scripts are plain .sql files on disk, so you back them up by copying them or committing them to version control, and you restore them by placing them back in the project and running them against a reconfigured data source. There is no automatic re-integration step and no special import wizard — the files are just SQL text.

What is confirmed vs. likely

Confirmed behavior of the IntelliJ-platform database tools (which Rider shares with DataGrip):

• Console scripts are stored as regular .sql files, typically under the project's .idea directory or a consoles/scratches location. You can confirm the exact path by right-clicking a console in the Database tool window and choosing Open in Explorer/Finder.
• Settings export (File > Manage IDE Settings > Export Settings) covers IDE configuration — keymaps, code styles, and data source definitions — not console file contents or query history.
• Data source definitions can be exported, but stored passwords may be excluded depending on your password storage setting (KeePass vs. OS keychain), so a restored console may not connect until credentials are re-entered.

Likely, but version-dependent: exact storage paths and the scope of Settings Sync vary by Rider release and OS. Inspect your own export archive to confirm what is actually included before relying on it.

What metadata survives a restore

Only the file contents. Execution history, result-set caches, and console session state live in IDE system/config directories and are not portable across reinstalls. Ad-hoc consoles that were never saved as named files may exist only in the config directory and can be lost entirely — treat anything important as a named, committed file.

Recommended persistence setup

1. Save important consoles as named .sql files inside the project (e.g., a db/queries/ folder) and commit them to Git alongside the code.
2. Export data source definitions via settings export, but store credentials separately (secrets manager or KeePass option) so a restore can reconnect.
3. After restoring, open the .sql files from the project, attach the reconfigured data source, and run them directly.

Verifying consistent results after restore

Rider does not store prior result sets in a restorable form tied to a script, so consistency must be verified against an equivalent database state:

• Restore against the same schema version and, ideally, a data snapshot or seeded test dataset.
• Rerun deterministic queries — COUNT(*), fixed aggregates, or queries over immutable reference tables — and compare against previously recorded values.
• For non-deterministic data, compare structural properties (row counts, checksums of ordered key columns) rather than exact output.

If you can share your Rider version and OS, the exact console storage path and Settings Sync coverage can be pinned down more precisely — but the file-level backup recommendation stands regardless.