When learning, you want to try and avoid juggling too much at once. You want to get something working, learn from it (including your mistakes), then iterate. For example, in your discussions about database, you’re trying to pick something based on several simultaneous criteria, including:
In the first instance, I wouldn’t worry too much about any of these, except perhaps a little of “stability” in the sense of “maturity” just so that you can concentrate on your own bugs without complications from library bugs.
I’d concentrate much more on the shape of your problem, and the kind of data model you think you’ll need to support: key-value vs relational, structured vs opaque (serialised blob) data, transactional vs eventual-consistency, etc. Redis, diesel->postgresql, and TiKV are all good data stores but very different choices along these criteria.
Make a basic architecture choice, pick something (almost anything) that’s a simple implementation of that model that you can start building with, and start building. Later, when you’ve learned more about your application logic, you can address infrastructure scaling and change from (say) sqlite to postgresql or from in-memory HashMaps to TiKV quite easily, and with a little more effort from (say) SQL-ish to KV-ish. You’ll learn about different aspects at different times, rather than trying to make all your decisions at once.