> 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.