Synchronous TM suggestions vs deferred indexing for concurrent Weblate edits

Question

Goal is to keep editor save latency predictable when multiple users edit the same project via Weblate UI or API.

Weblate stores translation units with Django ORM transactions. Background work for commits, translation memory indexing and machine translation suggestions runs via Celery on the same database. With default queues, UI requests can contend for I/O and lock time under parallel load.

Operators face an unresolved trade-off between keeping live translation memory suggestions enabled for immediate editor feedback and deferring or limiting those lookups to reduce request queuing. Weblate does not define a default strategy for live TM search under load.

What configuration determines synchronous versus deferred translation memory suggestion behavior? Is the trade-off documented for PostgreSQL versus SQLite deployments? Which signals indicate that TM work is contributing to latency under concurrent saves?

Tasadduq Burney · Answer

Synchronous vs. Deferred TM Behavior
Weblate does not provide a single toggle switch to flip Translation Memory (TM) suggestions between "synchronous" and "deferred" modes. Instead, the behavior is a result of how the application handles the save event: the translation unit is updated via the Django ORM (synchronous), while the indexing of that unit into the TM for future suggestions is dispatched as a background task via Celery (deferred).

The Performance Trade-off
The perceived latency during concurrent edits usually stems from database lock contention rather than the TM lookup itself. Because Weblate uses Django transactions, a high volume of concurrent saves can lead to I/O wait times, especially when Celery workers are simultaneously writing index updates back to the same database.

Factor
      Synchronous (ORM Save)
      Deferred (Celery Indexing)

Impact
      Immediate unit update; locks row.
      Updates TM search index.

Latency
      Directly affects UI response time.
      Affects how soon others see the suggestion.

Risk
      Request timeouts under heavy load.
      Propagation delay (stale suggestions).

Database Deployment Considerations
The trade-off varies significantly by backend:

PostgreSQL: Better handles concurrent writes and row-level locking. Latency is typically tied to disk I/O and the number of available database connections.
  SQLite: Highly susceptible to database is locked errors during concurrent edits because it employs database-level locking for writes. SQLite is not recommended for multi-user concurrent editing environments.

Identifying TM-Induced Latency
To determine if TM work is contributing to save latency, monitor the following signals:

Celery Queue Depth: If the queue for indexing tasks grows indefinitely, the system is struggling to keep up with the edit volume, which can saturate DB I/O.
  Database Lock Wait Time: Use pg_stat_activity (for PostgreSQL) to check for queries stuck in a "waiting" state during peak save windows.
  Request-to-Suggestion Delta: Measure the time between a user saving a string and that string appearing as a suggestion for a second user. A widening gap indicates deferred indexing bottlenecks.

Missing Diagnostic: Are you utilizing a separate database instance for the Celery broker/backend, or is everything sharing a single PostgreSQL instance?

Synchronous TM suggestions vs deferred indexing for concurrent Weblate edits

1 answer

Synchronous vs. Deferred TM Behavior

The Performance Trade-off

Database Deployment Considerations

Identifying TM-Induced Latency

Your perspective belongs here.

1 question comment

TM suggestion latency and table indexing

Factor	Synchronous (ORM Save)	Deferred (Celery Indexing)
Impact	Immediate unit update; locks row.	Updates TM search index.
Latency	Directly affects UI response time.	Affects how soon others see the suggestion.
Risk	Request timeouts under heavy load.	Propagation delay (stale suggestions).