What strikes me as odd is people wanting to write things that traditionally are written in C/C++ and more recently also in Go/Rust/Java/D in JS. The reason these arguably slower, in development speed, languages are used for things like DBs is that they are write once re-use thousands of times, and this use case warrants being slightly lower level and less rapid in development and gaining performance and I would argue maintainability.
[1] Note: In case you are wondering why I dislike JS: 1. JS's extensive use of spaghetti cough I mean callbacks 2. Higher effort needed to use compute resources for a single task in a parallel fashion compared to other langs 3. I dislike dynamically typed languages (I belive they are harder to maintain) 4. Performance: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
I should note I know people who make this choice. They can write these things in C, and in the past, they have. But they are choosing Node.js. So it's not just a "what you know" affect.
But if you need multiple programs to use your DB at once you need a more powerful solution such as MongoDB. The goal of NeDB is to bring DB features to desktop apps or low concurrency webapps, not replace Mongo and the like.
And append-only doesn't make you immune to corruption. There's still a possibility of two processes writing at the same time corrupting what gets written to the file.
At first I was trying to think of words that start with "ne-" before I clicked through and realized "E" stood for something on its own :-)
a) and b) The database is loosely coupled with the query language implementation, so it could be possible to change the query semantics without breaking it. That said I have other priorities for now (some adaptation for Node Webkit, porting it to the browser).
c) NeDB queries return vanilla objects or array of objects , on which you can use all the underscore functions you want.
d) Depends what you want to do. If you want to write a REPL I think it shouldn't be too difficult, and it may be a good idea to do one. In the meantime, since the API is the same as MongoDB's, you can learn NeDB using MongoDB's REPL :)
You can use that once you've outgrown NeDB.
Amongst those are a native SQL engine (sqlite) and a native NoSQL engine (levelDB, through the IndexedDB API)
It'd be useful to know what benefits NeDB brings over other existing storage mechanisms.
If it is, you should probably put a larger warning about dataset size than the line you currently have :)
As an aside, I'm considering enabling large datasets for NeDB as some users asked, but that would be a lot of work so I'll wait for more requests.
1: https://github.com/louischatriot/nedb/blob/b1abd34384cefea16...
