RFC: TiDB storage backend

[ngaut]

What

Adds docs/rfcs/0000-tidb-storage-backend.md, a draft RFC for adding TiDB as a first-class optional ExtendDB storage backend.

Why

The implementation prototype in #140 was marked deferred pending an RFC. This RFC tracks the design discussion requested by the maintainer and links to tracking issue #141.

Related: #140
Tracks: #141

Testing done

• git diff --check
• ASCII-only RFC check with perl -ne 'print "$ARGV:$.:$_" if /[^\\x00-\\x7F]/' docs/rfcs/0000-tidb-storage-backend.md
• /tmp/extenddb-docs-venv/bin/python docs/build-docs.py

Checklist

• I have read CONTRIBUTING.md
• Code is formatted (cargo fmt --check) - documentation-only PR
• I have updated documentation if behavior changed
• This PR is the RFC for the proposed storage/backend and CLI/config surface changes

ADR / RFC: this PR

[navareamol]

Thank you for submitting the RFC for TiDB storage backend. We're reviewing your submission and debating on certain feature sets in the RFC. We will circle back with detailed response by 7/9.

[LeeroyHannigan]

Thanks for the thorough RFC, @ngaut this is well thought through and we're happy to accept TiDB as an optional backend along these lines. The backend-additive, backend-owned-implementation approach is the right call.

A few DynamoDB-parity points to fold in before/with implementation, split into what must match vs. what's fine to differ as long as it's documented:

Must match DynamoDB (observable-behavior breaks otherwise)

• TTL + Streams: relying on native TiDB TTL means expired items won't emit REMOVE stream records, that's a breaking gap, not just a caveat. When streams are enabled, TTL deletes must go through an ExtendDB path that emits DynamoDB-compatible REMOVE records.

• Key ordering/equality: DynamoDB compares String keys by case-sensitive UTF-8 byte order and Numbers as exact decimals (up to 38 significant digits). The generated index-key columns must use a binary collation (not MySQL's default case-insensitive collation) and a decimal type for numeric keys, or Query ordering and key equality will diverge.

• Number fidelity: items must round-trip numbers as exact decimals, JSON storage must not coerce them to floats.

• Conditional/transactional writes: must stay atomic (no write-skew) and keep surfacing ConditionalCheckFailedException / TransactionCanceledException as today.

Fine to differ, just call it out

• GSI consistency: maintaining indexes transactionally makes GSI reads strongly consistent instead of eventually consistent. That's acceptable (stricter than DynamoDB) please document it as an intentional backend difference, and still reject ConsistentRead=true on a GSI so the API surface matches.

• Point-in-time window: snapshot-backed reads are bounded by TiDB's GC lifetime, so the effective PITR/export window is shorter than DynamoDB's 35 days. Fine to ship with a documented limit.

Also please keep sparse-index/index-key type rules and projection (KEYS_ONLY/INCLUDE/ALL) enforced at read time, since items are stored once.

Overall: accepted in principle, let's nail down the TTL-stream path and key-encoding details, then move to implementation behind the opt-in feature. Thanks again for the careful write-up!