No problem. Note though that FleetDB is all in memory too. The advantage is that you can:
1. Put the database on its' own server with dedicated RAM.
2. Compose and re-use queries.
3. Have index support, built in, without code writing.
4. Have robust/high performance concurrency semantics, not just atomic file writes.
> Databases don't get away with it. Once the app data can't fit into memory databases thrash on disk too.
You're correct in that they too will do seeks to disk, but nowhere close to the same amount when compared to handling each record in it's own file. Just try loading a million files vs 1 file with a million records.
> But even then, save-table could be modified to save each field in a separate file.
Which will exponentially increase the number of disk seeks.
As I stated before it really depends upon your design. Ask yourself: Are you going to have say a million records where you have to run a query againts all records?
Would indexes help with that query on that data? Do you really want to code each index into a table then change all your application code to use them? Or would you rather instruct your database to add an index and discover the existing queries already take advantage of them?
Note that the last time I checked, HN off loaded that kind of heavy lifting to a third party service[1] that uses[2], you guessed it, a database!
I am not a database expert and I don't want to convince you to use tool that you don't need to use. I'm just saying I see enough advantages in using a database that I don't plan on using file writes.
