>It doesn't scale out, only up, is a fairly big limitation. This is the main limitation. That being said you can scale out with projections if event sourcing i

>It doesn't scale out, only up, is a fairly big limitation. This is the main limitation. That being said you can scale out with projections if event sourcing is your thing. >It doesn't support multiple simulataneous writes (like PostGres and SqlServer etc). A process with a single writer tends to be faster because it reduces contention. You only need MVCC in postgres because of the network. What's even better is you can query across multiple databases seamlessly with ATTACH (https://sqlite.org/lang_attach.html https://sqlite.org/lang_attach.html). So it's very easy to split databases (eg: session database, database per company etc). Each database can have its own writer and eliminating contention between data that doesn't need to have atomic transaction across databases. >No stored procedures or functions. It's an embedded database the whole thing is effectively a stored procedure. You can even extend SQLite with your own custom functions in your application programming language while it's running (https://sqlite.org/appfunc.html https://sqlite.org/appfunc.html). In terms of access by multiple applications etc, if it's read access you can create read replicas/projections with litestream etc.