BEGIN CONCURRENT/MVCC rejected via Embedded Replicas — is a Python equivalent of @tursodatabase/sync planned?

[vmnarayan-byte]

Environment: libsql 0.1.11 (PyPI), Python 3.12, Embedded Replicas pattern (libsql.connect(local_path, sync_url=..., auth_token=...)), against a Turso Cloud database (aws-ap-south-1/Mumbai region, free tier).

What I tried

Following the MVCC docs (PRAGMA journal_mode='mvcc' + BEGIN CONCURRENT):

conn = libsql.connect("local.db", sync_url=DB_URL, auth_token=AUTH_TOKEN)
conn.execute("PRAGMA journal_mode='mvcc'")
conn.execute("BEGIN CONCURRENT")
conn.execute("INSERT INTO some_table (...) VALUES (...)")
conn.execute("COMMIT")

The write forwards to the primary and is rejected with a genuine parser error:

ValueError: Hrana: `api error: sqlite3Parser: near ID, "Token(Some("CONCURRENT"))": syntax error`

(Also tried testing this via the Turso dashboard's SQL Console directly, bypassing the driver — but that runs on Drizzle Studio, which auto-strips BEGIN/COMMIT/END/ROLLBACK to build its own transaction wrapper and can't run an explicit BEGIN CONCURRENT at all, so that path isn't meaningful evidence either way. The driver-level result above is the only clean signal I have.)

Questions

1. Is BEGIN CONCURRENT/MVCC supported at all when writes are forwarded from an Embedded Replica to a Cloud primary via this driver, or is it local-file-only / does it require a database-creation-time opt-in rather than a client-side PRAGMA? Is this a free-tier limitation specifically?

2. While digging into this, I found tursodatabase/turso-sync-benchmark, which benchmarks @tursodatabase/sync (the JS/TS push/pull CDC protocol) against Embedded Replicas and explicitly calls the latter "the legacy approach." It also documents a real conflict-resolution model (rebase for non-overlapping column updates, last-push-wins + an optional transform callback for same-column conflicts). That looks like it might be the actual modern answer to concurrent writes against a Cloud primary, superseding SQLite-native MVCC pragmas for this use case — is that read correct?

3. Is a Python equivalent of @tursodatabase/sync planned? I couldn't find one anywhere in the tursodatabase org — every sync-related repo (embedded-replica-examples, turso-sync-benchmark) is JS/TS only. Until/unless one exists, is there a recommended pattern for handling concurrent writes from Python clients, or is single-writer-per-primary (with app-level batching, e.g. hand-built multi-row statements as in Optimize executemany() and executescript() to use batch requests #70) the intended model for Python indefinitely?

Happy to provide the full repro script if useful.