[cynicalsecurity]

Sqlite doesn't work super well with parallelism in writing. It supports it, yes, but in a bit clunky way and it still can fail. To avoid problems with parallel writing besides setting a specific clunky mode of operations a trick of using a single thread for writing in an app can be used. Which usually makes the already complicated parallel code slightly more complicated.

If only one thread of writing is required, then SQLite works absolutely great.

[bob1029]

> If only one thread of writing is required, then SQLite works absolutely great.

The whole point of getting your commands down to microsecond execution time is so that you can get away with just one thread of writing.

Entire financial exchanges operate on this premise.

[chatmasta]

Entire financial exchanges are not running single threaded writes to their persistent data store. If they are, and you have a link, I’d love to be proven wrong.

[_1tem]

https://use.expensify.com/blog/scaling-sqlite-to-4m-qps-on-a...

[bob1029]

https://www.infoq.com/presentations/LMAX/

[diziet_sma]

These aren't financial exchanges, they're a sports betting and an expense management system.

I share OPs skepticism. Market makers invest in microwave towers, FPGAs, etc. I would be surprised if sqlite backed by NVME is on the other end of all that specialized hardware.

Order matching is a single threaded thing though. I would be curious if anyone knows how electronic trading systems are actually implemented.

[bob1029]

> I share OPs skepticism

> I would be surprised if sqlite backed by NVME is on the other end of all that specialized hardware.

I was not making this assertion. I am surprised anything like it got inferred (i.e., my use of the word "premise" regarding single thread/writer policy).

I agree that what you describe would be ridiculous in practice.

> I would be curious if anyone knows how electronic trading systems are actually implemented.

> Order matching is a single threaded thing though.

I think you answered your own question.