| Files | Last commit | Last update |
|---|---|---|
feat(cli): add inspect db toast-sizes command (#6528) ## Summary Adds `supabase inspect db toast-sizes` — a new `inspect db` subcommand that lists user tables with TOAST storage, ordered by TOAST size (largest first). ## What changed - `apps/cli/src/commands/inspect/db/toast-sizes/` — 3-file subcommand (query, handler, command) - `apps/cli/docs/supabase/inspect/db-toast-sizes.md` — docs overlay with description and sample output - `apps/cli/src/commands/inspect/db/db.command.ts` — registers the new subcommand - `apps/cli/src/commands/inspect/db/SIDE_EFFECTS.md` — updates active count (13 → 14) and query table - `apps/cli/src/commands/inspect/db/inspect-specs.integration.test.ts` — adds a test case for `toastSizesSpec` ## Why it matters TOAST (The Oversized-Attribute Storage Technique) is PostgreSQL's overflow storage for large values in `TEXT`, `JSONB`, and `bytea` columns. Autovacuum runs on TOAST tables **independently** from the main heap, so dead TOAST chunks accumulate silently. A high TOAST dead-tuple ratio increases I/O and inflates effective database size — but it doesn't appear in the existing `bloat` or `vacuum-stats` commands, which only cover the main heap. This command surfaces: - Heap vs. TOAST size split per table - Live/dead TOAST chunk counts and dead-chunk percentage - Last autovacuum/vacuum timestamps on the TOAST table It's a common source of invisible bloat, especially in tables with large JSONB columns. ## Testing - New integration test case in `inspect-specs.integration.test.ts` (count updated 13 → 14) - Query filters out internal Supabase schemas via the shared `$1` LIKE-escape parameter (consistent with `bloat`, `vacuum-stats`, `index-stats`, `table-stats`, `db-stats`) - Docs overlay at `apps/cli/docs/supabase/inspect/db-toast-sizes.md` follows the same format as existing overlays ## Docs A follow-up PR to `supabase/supabase` will add this command to the [Inspect guide](https://supabase.com/docs/guides/observability/inspect) under the **Disk Storage Analysis** section after this merges. --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: avallete <andrew.valleteau@supabase.io> | 3 days ago | |
test(cli): cover migration and seed ordering (CLI-2581) (#7521) ## TL;DR adds `start` and `db reset` ordering cases to the contract suite for migrations, seeds, config buckets and service schemas the audit found no ordering difference between backends, only the already documented stack `db reset` warning on a rejected bucket upload ## ref: - closes: CLI-2581 | 22 hours ago | |
feat(config): read and write config.jsonc and commented JSON configs (CLI-2860, CLI-2861) (#7488) ## Summary The CLI now reads and writes `supabase/config.jsonc`, and treats `config.json` the same way, so comments and trailing commas work and survive every write the CLI makes to the config. Reading: - The loader looks for `config.json`, `config.jsonc` and `config.toml` in `supabase/`. `config.jsonc` reports `format: "json"`, so everything that already handles a JSON config treats it the same way - Both JSON files go through `jsonc-parser`. A syntax error now names its position, e.g. `Comma expected (line 4, column 3)`, instead of the runtime's `JSON.parse` message - The CLI warns once per command when a JSON config shadows `config.toml`: `Ignoring supabase/config.toml because supabase/config.json takes precedence. Delete the file you don't use.` - The two comment strippers the CLI had (VS Code settings in `init`, Deno import maps in `functions deploy`) use the same parser now, and the experimental-feature reader and the upgrade notice's project walk-up know about `config.jsonc` Writing: - `config pull` edits a JSON config in place through `jsonc-parser`'s `modify` instead of re-serialising the whole file, so comments, trailing commas and untouched values stay as they are. A new key goes after the previous property's whole line, so a trailing comment stays with its own key. ADR 0023 has an addendum for the new JSON strategy - `saveCliConfig` applies the same minimal edits when it saves over an existing `config.json`/`config.jsonc`, and removes a dropped key by its whole line. Removing the last key of an object also drops the comma before it, so a `config.json` stays strict JSON for older CLIs. If the edited text doesn't re-parse to exactly the saved config, it falls back to writing the regenerated file. A TOML save keeps the file's `#:schema` line - `saveCliConfig` writes back to `config.jsonc` when that's the project's JSON file, and still removes the other config files after the write - `compute new` (experimental) records the new compute in a JSON config through the same editor, instead of refusing - `functions new` and the declarative `db pull` write their `functions.<slug>` and `db.migrations.schema_paths` entries into a JSON config through the same editor. Before, both appended TOML to a new `config.toml` that the JSON file shadowed, so the setting never applied - `init` treats an existing `config.json`, `config.jsonc` or `config.toml` as an existing config and names that file when it refuses. `init --force` and a blank `bootstrap` remove `config.json`/`config.jsonc` when they write the fresh `config.toml`, so the new template is the file that gets read Messages: - Errors, hints and suggestions that named `supabase/config.toml` or gave TOML syntax now name the project's own config file and write the key in its syntax. A TOML project still sees `[db] major_version = 17`, and a JSON project sees `` `db.major_version` to `17` in supabase/config.jsonc ``. Where the command has no config loaded, the text says "your config file" or lists all three file names - Command help says "the project config file" and uses dotted keys such as `db.seed.sql_paths` - `db-config.toml-read.ts` is renamed to `db-config.read.ts`, since it reads every format `jsonc-parser` is a new runtime dependency of `@supabase/config` (MIT, no dependencies of its own). Its `parse()` turns a `__proto__` key into the object's prototype, so `parseJsonc` builds values through its `visit` API with own-property assignment instead. ## Behaviour changes for existing projects - A `config.jsonc` next to `config.toml` now takes over from it. Before, `config.jsonc` was never read. The new warning names `config.toml` as ignored, so the switch shouldn't go unnoticed - `config.json` and `config.jsonc` in the same `supabase/` directory is now an error: `Found both supabase/config.json and supabase/config.jsonc. Keep one and delete the other.` Before, `config.jsonc` was ignored - Projects that already had `config.json` next to `config.toml` now get the warning above. `config.json` already won there, so which file is read doesn't change - `config pull` and `saveCliConfig` on a `config.json` now only change what they write. Before, both rewrote the whole file - The stack's advice to pin a service version now reads ``pin `local.services.<service>.version` to "<version>" in your config file`` for every project, including TOML ones - Errors for a missing project config name `supabase/config.toml, config.json or config.jsonc` instead of only `config.toml` - `init` in a project with only a `config.json`/`config.jsonc` now reports the config as already there. Before, it wrote a `config.toml` that the JSON file then shadowed. `init --force` in such a project now removes the JSON file ## Linked issue Closes CLI-2859 Closes CLI-2860 Closes CLI-2861 🤖 Generated with [Claude Code](https://claude.com/claude-code) | 1 day ago |