[ioquatix]

Relaxo actually grew out of Couch DB.

Relaxo used to be a couch query server (https://github.com/ioquatix/relaxo-query-server - not so useful any more) and ruby front end (https://github.com/ioquatix/relaxo-model - still useful). But I got frustrated with the direction of couchdb 2.x so I rewrote it to do everything in-process and use git as the document store. It organically grew from that.

Unless you are operating at scale, doing things in-process is vastly more convenient. Sending ruby code to the query server to perform map-reduce was a cumbersome process at best. It's easier just to write model code and have it work as expected.

Systems like Postgres a great when you have a single database and multiple front-end consumers though. You'd need to put a front-end on top of relaxo in order to gain the same benefits, but it would be pretty trivial to do so - just that its never been something that I've needed to implement. The API you'd actually want is one that interfaces directly with your Ruby model instances, rather than database tables and rows. I think there is room for improvement here - probably implementing a websocket API that exposes the raw git object model and then allowing consumers to work on top of that.

[deitcher]

Pretty cool. Is there a write up on architecture and usage models? I’d like to see it.

I was a happy couch 1.x user, but moved away with 2.0. Nothing specific about it, just needs and timing.

[ioquatix]

Thanks for being so interested.

The architecture is super simple, I'd suggest that the first place to look is the source code.

There are really only two ways of accessing the underlying data store - a read-only dataset and a read/write changeset which can be committed.

It's purely a key-value storage at the core - a key being a path and a value being whatever you want.

On top of that you can build more complex things, e.g. https://github.com/ioquatix/relaxo-model which provides relational object storage and basic indexes (e.g. has one, has many, etc)