So if you have a single DB server running sqlite and your server goes down, well, your shit is down and there is no failover. I.e. no built in replication or clustering.
It doesn't support multiple simulataneous writes (like PostGres and SqlServer etc).
No stored procedures or functions.
There is no real client/server architecture. i.e. if you have applications on multiple servers which need access to the DB then you're in a bad place. The database has to be embedded along with the application.
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). 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).
In terms of access by multiple applications etc, if it's read access you can create read replicas/projections with litestream etc.
So, what are the limitations compared to Postgres?