I've recently been doing quite a bit of wrestling with SQLite and concurrency. It's sort of a bitch, but it IS doable.
The issue is, when you issue writes to a SQLite database you lock the entire thing (in comparison to row locking, which other solutions support). If you're issuing tons of writes from multiple locations/threads, you're going to wind up hitting walls when 'database locked' errors show up.
I think it's possible to increase the timeout on SQLite queries so these issues become... slightly smaller issues. They are still issues nonetheless.
Another issue you may run into with SQLite is using FOR UPDATE. This is used when you need to retrieve some rows, compute things given the data, then issue an update without other queries reading those rows in the meantime. It does not support such a construct. You can get around it, but you have to explicitly lock the entire database while you do this update (you'll see someone addressing this here).
Concurrent reads are fine, so maybe it will work for you.
I suppose the TL;DR of this whole thing is that it depends on how many concurrent hits you expect to be having on the database. If you expect a lot, perhaps you should look into a more robust database solution like postgresql.
I'm not a database expert by any means, but I hope that points you in the right direction.