StrokeDB design emphasizes the concept of schemaless documents residing in a global space and connected between each other using references (“hyperlinks”). You can implement a relational database in a sixth normal form using StrokeDB, but you are never constrained to a strict relational model and can violate it any time you want.
There’s nothing wrong with relational model itself. It is just a mathematical concept, “SQL interface”, that’s it. The most interesting thing is an actual implementation. Most of us experience hard to solve issues with MySQL or PostgreSQL because of how they store data and what requirements they put upon a user. StrokeDB is also a relational database, but it is not limited to this model and is not specifically optimized for this model only.
See “The Death of the Relational Database” describing some issues with RDBMS.
Forget about migrations. You would only need some Rake tasks to modify either existing documents, or existing indexes. Migrations in such case is a must-have, and you know what? They could be stored right in your database and do their job automatically, when current database replica is known to be stale (e.g. metadocument described in a source code was not found in a storage).
StrokeDB offers straight-forward object-oriented wrapper for JSON data.
It is much easier to hack, extend and optimize, than ActiveRecord.
Compare these snippets from a real-world application to get an idea.
You may configure your production, test and development databases differently and use the very same data in them easily. You may run production database on a cluster, develop with a portion of that data on your local disk and run tests keeping all the documents in a fastest memory storage. You won’t need any dirty tricks faking your SQL database with in-memory fixtures.
StrokeDB is easier at caching. Actually, there is no need in implementing and maintaining a cache. Instead, you may just configure a chain of in-memory and file-based storages for the fast and correct access to the frequently used data. (Memcached may be used as well.) This is a huge thing for those, who hate debugging cached data on production machines.
CouchDB is very nice, but has several disadvantages for us.
We plan to port a kernel of the StrokeDB to “thin client” languages
with the very same features server version has. CouchDB is written
in Erlang and that’s the first problem.
Another thing is that CouchDB doesn’t scale data properly yet. It lacks distributed indexes and storages.
There’s also a huge argument for pure-Ruby version: StrokeDB integrates so well with Ruby apps, so it is a pleasure to configure different environments and optimize performance by injecting the database right into your application.
ThruDB is less nice, than CouchDB :-) It has even simpler
data storage facilities and lacks some important features (like revision control).
Unfortunately there’s more marketing buzz, than actual documentation.
All the concerns about CouchDB are also applicable to ThruDB. However, we have stolen several interesting design ideas (e. g. storage chaining) from ThruDB.
The first concern about it is non-technical. Oracle is hard to work with for the very simple reason: very difficult to configure, very difficult to find gurus working with it day to day, and it is not an open source. But most importantly, it is still a RDBMS. With the same useless advanced features (e.g. foreign key constraints, stored procedures etc.), and there’s still no facility for partial replication and revision tracking. Scalability aspects are under a big question mark: they seem to be very advanced, but we don’t have any time or passion to investigate this in deep.
GemStone is a powerful persistance layer above the native Smalltalk object database. We could use GemStone if we’d worked with Smalltalk instead of Ruby. But we’ve chosen latter. C’est la vie.
In case we’ve missed something on this topic, you can always contact us and give some advice.
It is poor comparing to MySQL, but it is probably comparable to SQLite. We have several benchmarks in the repository, however we have not yet compared performance between SQLite, MySQL and StrokeDB. When several mission-critical features are ready, we will prepare a shootout benchmark suite.
We don’t care much about performance for now. The most important thing is to improve API and get it running in a distributed environment. However, we have an interesting facility for portable optimizations already (lib, usage).