Mattermost SQLite write concurrency limits for low-traffic production

Question

Mattermost offers SQLite as an embedded database option, which can remove the cost of a separate PostgreSQL server for a low-traffic workload. Documentation describes SQLite as suitable for evaluation and small teams, while warning of write-locking contention under concurrent write loads. PostgreSQL remains the only recommended production database for high availability, and no official guidance quantifies a maximum safe user count or message rate for SQLite.

The goal is to determine whether SQLite can safely serve a small, low-traffic production deployment without a separate database instance, given the absence of defined concurrency limits.

What concurrent write volume or active user count represents the practical boundary for SQLite-backed Mattermost before write-lock errors become likely?
Is SQLite officially supported for production use in single-server, low-traffic deployments that do not require high availability?
What backup and migration constraints should be evaluated before choosing SQLite over PostgreSQL for cost reduction?

Tasadduq Burney · Answer

SQLite Write Concurrency in MattermostConfirmed FactSQLite operates via file-level locking, meaning only one process can write to the database file at any given moment. This fundamental behavior dictates that concurrent write operations will result in serialization, leading to write-lock contention errors under sustained load, regardless of how 'low' the traffic is if writes overlap.Likely ExplanationThe absence of a defined safe user count or message rate is due to the nature of file locking, not a configurable limit. Low traffic only reduces the *frequency* of contention, not the *possibility* of it. If multiple users attempt to post messages or update status concurrently, a lock conflict is probable.Required Steps for Low-Traffic DeploymentEnsure the Mattermost instance is running on a stable, non-contended filesystem (e.g., local SSD, not network share).Implement robust application-level retry logic within Mattermost or the deployment wrapper to handle expected `SQLITE_BUSY` errors gracefully.Monitor Mattermost logs specifically for SQLite write-lock error messages during initial low-volume operation.Missing Diagnostic DetailTo refine the recommendation, what is the expected *peak concurrent write rate* (e.g., messages/second) rather than just the average low traffic?

Mattermost SQLite write concurrency limits for low-traffic production

1 answer

SQLite Write Concurrency in Mattermost

Confirmed Fact

Likely Explanation

Required Steps for Low-Traffic Deployment

Missing Diagnostic Detail

Your perspective belongs here.

1 question comment

Concurrency, not headcount, is the relevant boundary