So the question is not whether to use files. You're always using files

I mean. this is incorrect straight off the bat, most industrial DB's built since the 90s are using some flavour of block store rather than file based abstractions.

In-memory map is the ceiling. 97k req/s with sub-millisecond latency at every scale. If your dataset fits in RAM, nothing on disk will match it.

Databases know this too hence obsession with using L1-L3 caches for as much as possible. Issue is knowing for certain that you never will exceed it or put too much pressure on the system while a lot is happening, or that you definitely don't care if you do have that problem.

None of these constraints apply to a lot of applications. Plenty of internal tools, side projects, and early-stage products will never have a dataset that doesn't fit in a single server's RAM, never need to join across tables under heavy load, and never run more than one instance. For those applications, this approach works.

So basically a technical problem with hardly any constraints it doesn't really matter how you solve it. Ok great insight. to take the code for instance

struct 
Store
 {
    users: 
RwLock
<
HashMap
<
String
, 
User
>>,
    file: 
Mutex
<
File
>,
}

impl 
Store
 {
    fn load(path: &str) -> 
Arc
<Self> {
        let mut map = 
HashMap
::new();
        if let 
Ok
(f) = 
File
::open(path) {
            for line in 
BufReader
::new(f).lines().flatten() {
                if let 
Ok
(u) = serde_json::from_str::<
User
>(&line) {
                    map.insert(u.id.clone(), u);
                }
            }
        }
        let file = 
OpenOptions
::new().create(true).append(true).open(path).unwrap();

Arc
::new(
Store
 { users: 
RwLock
::new(map), file: 
Mutex
::new(file) })
    }

    fn get(&self, id: &str) -> 
Option
<
User
> {
        self.users.read().unwrap().get(id).cloned()
    }
}

This implementation is moronic to try to replicate a database. If your whole point is you don't care about concurrency why even bother with a RwLock? If you do care to the extent of a database then you're using a spin lock rather than jumping straight to a RwLock first time round and you'd still have problems as any reader is blocking writes over a Mutex. Which we have on the file. So Now we can have a fun situation of users being locked while you're file is not locked.