Generally that's a good approach. :)

In this case though, it seems a bit weird.

SQLite is widely known to be for single writer workloads, whereas PostgreSQL is similarly widely known for being extremely good in concurrent usage scenarios.

Those are the things they're each designed for. eg:

https://www.sqlite.org/whentouse.html (the "High-volume Websites", "High Concurrency", and "Many concurrent writers?" pieces)

Feel free to run benchmarks to demonstrate this to your own satisfaction though. :)

Well I explained my rationale above - writes are sequential on the disk level regardless the database. So PostgreSQL shouldn't have much of an advantage in concurrent simple writes (it could even be slower than SQLite). PostgreSQL should be faster in concurrent complex transactions but the question is how complex and how much faster.

Good point. That's a reasonable place to start investigating from.

Personally, I can't be bothered (to much higher priority stuff to do). But if someone else gets around to testing this specifically, I'd be interested in the answers as well just to "make sure" the common understanding isn't wrong. :)