[trailbase]

> So it seems to target only very simple applications, eg. straightforward relational DB <-> Json Rest/HTTP.

Could you expand a bit on what more advanced capabilities you're missing for anything beyond a very simple app? I'm genuinely curious but also see SQLite often undersold

[aprilfoo]

Processing beyond simple DB data retrieval or io dependent processes can be time consuming and fully justify a cache. Eg, geographic processing that goes beyond geoDB capabilities with millions of rows, eventually involving retrieval of data from third party providers can take long so you'll want to cache results one way or another.

No denying SQLite is very capable. However in my understanding it's designed for being used by a single application, it's not really scalable, and its functionalities are still limited compared to the big DBs. Anyway there's no single fit for all cases, and for core components flexibility is really important.

[trailbase]

Thanks for expanding.

> retrieval of data from third party providers can take long so you'll want to cache results one way or another.

Agreed. Caching of slow external sources will always be beneficial (at least if you need it more than once :) ). You should use whatever makes the most sense. The argument is more that data from TB is already pretty quick, quick enough that you could even use it as a cache.

> However in my understanding it's designed for being used by a single application,

SQLite by design allows for concurrent writes and parallel reads from any number of processes.

> it's not really scalable,

What do you want to scale to? Postgres is fairly similar in terms of scalability, i.e. master writes + read replicas. Once you're going beyond that scale you get a lot more benefit out of more specialized, problem-oriented solutions.

> and its functionalities are still limited compared to the big DBs.

It full SQL and it's extensible. Depends on what you need. It certainly doesn't have the same rich ecosystem or flexibility of posgres where you can even swap out the storage engine. I was mostly curious, if there's some specific functionality you're missing.

> and for core components flexibility is really important.

Agreed: the right kind of flexibility for your problem.

I'll play devils advocate here: imagine you'd start to deeply depend on one specific postgres plugin and then that plugin get discontinued or you're hitting performance bottlenecks and you're to locked-in to move to a more specialized solution. Don't take this too seriously, I just wanna say that there's a balance.