docs(caching): a declared primary_key is a row constraint, not the cache key The caching refresh-mode page said a declared `acceleration.primary_key` replaces request metadata as the cache key, and its worked example passed a YAML list. Neither is true. A cache lookup is built from the request alone, so a key over response fields could not serve one even in principle; `primary_key` is a uniqueness constraint on the rows the accelerator stores. And `primary_key` deserializes as a string in every release, so the list form never parsed — the whole Spicepod is rejected at load. The example now projects the response fields it keys on with a `columns:` block and passes the key as a parenthesized string. That projection is only available from v2.0.0, so the 1.10.x and 1.11.x copies drop the example instead and state what a key can name there.

Release Post for v2.0-stable (#1812) * Release Post for v2.0-stable * fix(release): resolve v2.0-stable docs build blockers * chore(release): update v2.0-stable post title * Update website/releases/v2.0-stable.md * fix cdc tag * cdc tag fix * fix(releases): migrate change data capture tag to cdc * docs(release): version v2.0-stable as latest Snapshot docs/ into versioned_docs/version-2.0.x/ via create-release.sh, promoting v2.0 to latest (/docs) and keeping trunk as Next (/docs/next). Fix off-by-one ../ in non-markdown links across 36 index files (in both version-2.0.x and trunk docs/) that resolve at /docs/next but escape above the docs root when built as the latest version, plus a cross-version anchor leak in v1.7 (scalar_functions#embed). Markdown (.md) links untouched. Verified with a clean npm run build. --------- Co-authored-by: Luke Kim <80174+lukekim@users.noreply.github.com>

docs(retention): retention_sql alone satisfies an enabled policy, and an incomplete one is now reported (#2174) Sources: spiceai/spiceai#13857 Co-authored-by: claudespice <claudespice@users.noreply.github.com>

docs(arrow): the hash index activates from `indexes` too, and `partition_by` is supported (#2168) * docs(arrow): the hash index activates from indexes too, and partition_by is supported The Arrow accelerator deployment guide's Known Limitations contradicted both the code and the Arrow feature pages on two counts. Hash-index activation: the guide said the index 'requires a primary_key constraint; unique constraints alone do not enable the index'. The runtime enables it on 'has_primary_key || has_indexes', so a secondary indexes entry alone (unique included) builds the index with no primary key at all. The same page's Capacity & Sizing section already said '(or secondary indexes entry)', so the page contradicted itself. The real edge the guide missed is the reverse: under refresh_mode: caching the primary-key constraint is stripped before the table is created, so a primary_key alone builds nothing there. partition_by: the guide said 'Not applicable'. Setting partition_by on engine: arrow remaps the engine to PartitionedArrow, which holds one MemTable per partition value. The DuckDB accelerator page and the Partitioning feature page both already tell readers to use engine: arrow for partitioned acceleration. * docs(hash-index): caching drops the primary key, not the whole index — indexes still activates

Release Post for v2.0-stable (#1812) * Release Post for v2.0-stable * fix(release): resolve v2.0-stable docs build blockers * chore(release): update v2.0-stable post title * Update website/releases/v2.0-stable.md * fix cdc tag * cdc tag fix * fix(releases): migrate change data capture tag to cdc * docs(release): version v2.0-stable as latest Snapshot docs/ into versioned_docs/version-2.0.x/ via create-release.sh, promoting v2.0 to latest (/docs) and keeping trunk as Next (/docs/next). Fix off-by-one ../ in non-markdown links across 36 index files (in both version-2.0.x and trunk docs/) that resolve at /docs/next but escape above the docs root when built as the latest version, plus a cross-version anchor leak in v1.7 (scalar_functions#embed). Markdown (.md) links untouched. Verified with a clean npm run build. --------- Co-authored-by: Luke Kim <80174+lukekim@users.noreply.github.com>

docs(turso): indexes are supported under MVCC since v2.0.0

Release Post for v2.0-stable (#1812) * Release Post for v2.0-stable * fix(release): resolve v2.0-stable docs build blockers * chore(release): update v2.0-stable post title * Update website/releases/v2.0-stable.md * fix cdc tag * cdc tag fix * fix(releases): migrate change data capture tag to cdc * docs(release): version v2.0-stable as latest Snapshot docs/ into versioned_docs/version-2.0.x/ via create-release.sh, promoting v2.0 to latest (/docs) and keeping trunk as Next (/docs/next). Fix off-by-one ../ in non-markdown links across 36 index files (in both version-2.0.x and trunk docs/) that resolve at /docs/next but escape above the docs root when built as the latest version, plus a cross-version anchor leak in v1.7 (scalar_functions#embed). Markdown (.md) links untouched. Verified with a clean npm run build. --------- Co-authored-by: Luke Kim <80174+lukekim@users.noreply.github.com>

docs(snapshots): snapshot files carry the engine extension, not .db Since v1.11.1 (spiceai/spiceai#9318) the snapshot filename ends in the acceleration engine's extension — .duckdb, .sqlite, .cayenne or .turso — via AccelerationEngine::snapshot_extension(). The examples still showed the pre-v1.11.1 ".db" suffix. Scoped to v1.11.x and later; 1.8.x-1.10.x correctly document ".db", which is what snapshot_filename() hardcoded in those releases.