If you have constant, multiple, concurrent writes on a non-append-only database, it is bound to perform poorly no matter what database you pick. SQLite in this case nicely points out that you probably have a major architectural issue in your application.
On more productive notes:
* Are you using WAL mode?
* Are you using Batch inserts/updates/upserts?
* Are you using `BEGIN IMMEDIATE` when you need DML? Suddenly upgrading from autocommit mode or `BEGIN DEFERRED` "DQL" transactions to `BEGIN IMMEDIATE` "DML" ones implicitly by suddenly starting DML on what used to be a sequence of DQL queries is bad on any database, but worse on SQLite;
> If you have constant, multiple, concurrent writes on a non-append-only database, it is bound to perform poorly no matter what database you pick.
This is obviously incorrect, since Postgres can handle more than one simultaneous write transaction just fine. The rest of your post is accurate, but this is an intentional design decision to simplify SQLite’s implementation, not some fundamental limitation.
On more productive notes:
* Are you using WAL mode?
* Are you using Batch inserts/updates/upserts?
* Are you using `BEGIN IMMEDIATE` when you need DML? Suddenly upgrading from autocommit mode or `BEGIN DEFERRED` "DQL" transactions to `BEGIN IMMEDIATE` "DML" ones implicitly by suddenly starting DML on what used to be a sequence of DQL queries is bad on any database, but worse on SQLite;