Merge pull request #5 from boringSQL/snapshot-store-refactor

refactor: snapshot storage now supports multiple databases per project

Author: radim

.cargo-husky/hooks/pre-commit

@@ -0,0 +1,6 @@
+#!/bin/sh
+
+set -e
+
+echo '+cargo fmt --all -- --check'
+cargo fmt --all -- --check

Cargo.lock

@@ -13,6 +13,7 @@ dbg_macro = "deny"
 
 [workspace.dependencies]
 dry_run_core = { path = "crates/dry_run_core" }
+async-trait = "0.1"
 chrono = { version = "0.4", features = ["serde"] }
 clap = { version = "4", features = ["derive", "env"] }
 pg_query = "6.1"
@@ -26,6 +27,7 @@ thiserror = "2"
 tokio = { version = "1", features = ["full"] }
 toml = "0.8"
 tracing = "0.1"
+zstd = "0.13"
 reqwest = { version = "0.12", features = ["json", "rustls-tls"], default-features = false }
 rmcp = { version = "0.8", features = ["server", "transport-io", "transport-sse-server", "macros"] }
 schemars = "1"

Cargo.toml

@@ -12,7 +12,6 @@ LLM/AI coding assistants are very good in writing code/SQL queries. But they are
 
 Some PostgreSQL MCP server ask you for the database connection. And to perform the administrative tasks you might need SUPERUSER permission. But that's like asking for problem.
 
-
 We've already seen where this leads: [production databases wiped by AI agents](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/), and [SQL injection in MCP servers](https://securitylabs.datadoghq.com/articles/mcp-vulnerability-case-study-SQL-injection-in-the-postgresql-mcp-server/) that were supposed to be read-only.
 
 The model doesn't need to *query* your database. It needs to *understand* your schema: the structure, constraints, statistics, and version-specific behavior. That knowledge is structural. It changes when you deploy a migration, not between queries.
@@ -107,7 +106,7 @@ If you can connect to a PostgreSQL instance (local, dev, or production), one com
 dryrun init --db "$DATABASE_URL"
 ```
 
-This creates `dryrun.toml`, the `.dryrun/` data directory, and introspects the database into `.dryrun/schema.json`. You're ready to go.
+This creates `dryrun.toml` (with `[project] id` and default profile), the `.dryrun/` data directory, and introspects the database into `.dryrun/schema.json`. Snapshots are keyed by `(project_id, database_id)`; set `database_id` per profile when a project has multiple databases (e.g. `auth`, `billing`). See [`docs/dryrun-toml.md`](docs/dryrun-toml.md) for the full config reference.
 
 ### Option B: Someone else has database access
 
@@ -134,6 +133,44 @@ dryrun lint
 
 All commands work offline from the schema file. Each project has its own `dryrun.toml` and `.dryrun/`, there is no global state. Add `.dryrun/` to your `.gitignore`.
 
+### Multiple databases per project
+
+`dryrun snapshot take` keys snapshots by `(project_id, database_id)`. The defaults work — `project_id` is your folder name, `database_id` is the actual database name from `current_database()`:
+
+```sh
+dryrun init --db "$AUTH_DB"            # captures auth
+dryrun snapshot take --db "$BILLING_DB" # captures billing into its own stream
+dryrun snapshot list --db "$AUTH_DB"    # only auth snapshots
+```
+
+For stable refs (and so `list` / `diff` can run without retyping URLs), declare profiles in `dryrun.toml`:
+
+```toml
+[project]
+id = "myapp"
+
+[profiles.auth]
+db_url = "${AUTH_DATABASE_URL}"
+database_id = "auth"
+
+[profiles.billing]
+db_url = "${BILLING_DATABASE_URL}"
+database_id = "billing"
+```
+
+Then:
+
+```sh
+dryrun --profile billing snapshot list
+dryrun --profile billing snapshot diff --latest
+```
+
+See [`docs/dryrun-toml.md`](docs/dryrun-toml.md) for all profile options.
+
+Every DB-related command (`init`, `import`, `probe`, `dump-schema`, `lint`, `drift`, `stats apply`, all `snapshot` subcommands) accepts `--profile` and falls back to the resolved profile's `db_url` and `schema_file` when the corresponding CLI flag is not provider.
+
+> **Note:** the MCP server is currently single-database. Using the default profile. Or the option is to run one `dryrun mcp-serve` process per database. Native multi-database support inside one MCP process is tracked in [#4](https://github.com/boringSQL/dryrun/issues/7).
+
 ## MCP server
 
 Add `dryrun` to your AI assistant. If you installed via Homebrew, `dryrun` is already on your PATH:
@@ -150,6 +187,8 @@ claude mcp add dryrun -- /path/to/dryrun mcp-serve
 
 That's it. The server auto-discovers `.dryrun/schema.json` in the current project. No database credentials needed, your AI assistant gets full schema intelligence from the offline snapshot.
 
+For projects with multiple databases, run one `dryrun mcp-serve` per database and add an entry per server in your client config. Native multi-database serving inside one MCP process is tracked in [#4](https://github.com/boringSQL/dryrun/issues/4).
+
 See the [Tutorial](TUTORIAL.md) for live database setup, SSE transport, and Claude Desktop configuration.
 
 ## More

README.md

@@ -22,3 +22,8 @@ serde_json = { workspace = true }
 tokio = { workspace = true }
 tracing = { workspace = true }
 tracing-subscriber = { workspace = true }
+zstd = { workspace = true }
+
+[dev-dependencies]
+cargo-husky = { version = "1", default-features = false, features = ["user-hooks"] }
+tempfile = "3"