# RFC: AnkiConnect Write Concurrency & SQLite Locking Over Loopback

**URL:** <https://forums.ankiweb.net/t/rfc-ankiconnect-write-concurrency-sqlite-locking-over-loopback/70184>\
**Category:** Development\
**Created:** [June 22, 2026, 6:56pm UTC](https://forums.ankiweb.net/t/rfc-ankiconnect-write-concurrency-sqlite-locking-over-loopback/70184 "2026-06-22T18:56:49Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Navi-gator](https://avatars.discourse-cdn.com/v4/letter/n/c57346/32.png) [@Navi-gator](https://forums.ankiweb.net/u/Navi-gator)\
**Post date:** [June 22, 2026, 6:56pm UTC](https://forums.ankiweb.net/t/rfc-ankiconnect-write-concurrency-sqlite-locking-over-loopback/70184/1 "2026-06-22T18:56:50Z")

</div>

### 1. System Topology & Infrastructure Context

I am designing a local-first, air-gapped personal knowledge loop deployed natively on an isolated Ubuntu environment. Before running this setup in production, I want to validate the core database behavior and locking mechanisms of Anki’s SQLite backend when subjected to high-volume programmatic writes over loopback.

```plaintext
[Host Machine: Ryzen 9 3900X (12C/24T) | 64GB RAM | Samsung 970 EVO NVMe]
 
 [Obsidian Vault] ◄───(Filesystem Watcher)───► [Transcription Engine]
        ▲ │
        │ (Bidirectional Syncthing Target) ▼ (Local Loopback 127.0.0.1)
 [Isolated Directory] ◄───(AnkiConnect API)───────► [Anki Desktop / Core SQLite]

2. Primary Engineering Question: SQLite Write Concurrency
To loop missed or flagged cards back into our Markdown repository for structural review, we utilize a local reverse-synchronization daemon running alongside the active desktop user interface. This daemon interfaces via the AnkiConnect loopback API to query, update, and modify note fields programmatically.

Lacking a centralized network timestamp coordinator in this air-gapped state, our primary concern is avoiding database write collisions, race conditions, or unhandled database-locked errors.

The Failure Mode: If an automated background process triggers a series of dense programmatic card updates or note modifications via the AnkiConnect socket loop at the exact millisecond a user executes a manual text edit or card suspension inside the native Anki Browser graphical interface, how does the underlying engine serialize the transactions?

Core Questions:

How robustly does the Anki core handle concurrent automated and manual SQLite write operations?

Are there known write-lock or transaction-collision edge cases within the desktop application lifecycle that a script developer must explicitly construct an application-side validation or retry queue for?

I want to ensure absolute database integrity over extended offline operational periods. Technical critique regarding SQLite concurrency limits or write-locking behaviors within the Anki core lifecycle is highly welcome.
```

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex002/uploads/anki2/original/1X/8f1279ababc5879d54e4838989f606cfe55af8c7.jpeg) [@system](https://forums.ankiweb.net/u/system)\
**Post date:** [July 22, 2026, 6:56pm UTC](https://forums.ankiweb.net/t/rfc-ankiconnect-write-concurrency-sqlite-locking-over-loopback/70184/2 "2026-07-22T18:56:58Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.