I don't disagree but I generally do this by putting thw abstractions in place ij the software. An example is for crud, use the (onion|hexagonal|whatever you wa

I don't disagree but I generally do this by putting thw abstractions in place ij the software. An example is for crud, use the (onion|hexagonal|whatever you want to call it) architecture, you business logic has nothing to do with how the data is stored persistently (or not), build your application using abstract APIs. It's slightly more code up from but if I was using a map in memory it is trivial to move to using redis if I build with the abstractions in place to begin with. Generally in the prototype stage I won't care about that either but I expect the prototype / poc code to be deleted. Same idea with SQLite, moving feom sqlite to a full blown database isn't that difficult but this is one of the places where I would conceded and say if you have the infra in place just use what is available, it may be easier to get a DB on thr current cluster in the long run if there is already a cluster that you can get a DB on. If you however are in a completely greenfields position and really have no idea where the product is going, sqlite scales to a decent amount of RPS and so does a simple go/rust server on a host. Many webservices really don't need more than that and not worrying about being distributed when you don't know if you ever do need to be distributed makes whole hosts of problems trivial to solve and allows you to use technologies that would usually be inconvenient.