I wrote something like this: https://github.com/stochastic-technologies/goatfish

I very much support NoSQL (schemaless, really) databases on SQLite, as it's a great RDBMS and schemaless databases are very handy for various things. I'd love an embedded Redis, but this is pretty much the second best thing.

hehe, I wrote something like this as well :P https://github.com/joelmartinez/TattooDB-Android

This particular one is for Android ... but I had/have plans on creating a version for objective-c and C# (for Xamarin). The idea is to have a cross-platform and dead simple to use schemaless data-store for mobile devices at the ready :)

Yes, it seems to close to want I want to do. I'll have a deeper look at goatfish.

It is not clear to me from the committed CoffeeScript how this will work, but is this going to build on top of ejdb project [0] mentioned here a month or so ago?

[0] https://github.com/Softmotions/ejdb

No it's something I've had in mind for many year and that I wanted to build and test before being forced to used MongoDB or EJDB.

The source is in /server/reserve.coffee

Cool, thanks. I will check it out this evening.

Why would you do this, instead of just building something on the metal?

On a slow platform (ok, an iPhone!) serialization of a 20 field object to a file is approximately 50x faster than running an update statement against SQLite.

You are giving up a LOT of performance, even with a platform that's relatively fast, such as SQLite.

You are right. On an iPhone, I will not use a SQL database.

Dealing with performance, ChocoDB is currently fast enough for me (2x times slower that classic SQLite ; my first version was 8x slower!)

how does this compare to pouchdb / touchdb?

they implement couchdb's api and replication, but are implemented in localStorage / sqlite (respectively).

TouchDB is interesting but not immediately accessible for my node.js projects. And CouchDB is to heavy for my needs.

ChocoDB wants to (re)experiment new ways of dealing with database. It want to keep it simple and accessible.

How does this compare to SQLite 4's key/value store?

I have to look deeper at SQLite4 spec...

I would say that my objective with ChocoDB is to make it accessible and useful to people who want to manage database structures and queries in a more natural way.

I want the database to help manage different types of relations: inclusion, group, structure, association...

Key/value is simple but it does not help to manage relations. Relational DB don't either help to manage different types of relations.

Would a graph database be closer to what you are looking to do?

Probably, but I haven't found yet my dreamed graph DB (serverless, Node.js compatible...).

what relations does a relational db not help with? (i thought they were basically an implementation of the relational model).

Being a child of, being included in...

You can of course manage all those relations in a relational database but the job is done by you, not by the database.

but isn't the point of being able to implement any relationship you want rather than having a few particular kinds (child of, included in) "built in" a feature? are you going to extend your database every time someone wants a different kind of relationship?

Yes, but usual relations could be implemented by default and generic relation still be available.

I just want to test this and see if the database can do more and my code less.

Seems like a lot of people are building databases these days.

Yes ;-)

I think there is a need for light embedded schemaless databases.