Auto-recovery of Primary Fault
Can your database do this? Warning, this database is written entirely in JavaScript, intended as an Open Source Firebase.
For those who can’t watch the video, I crash the “primary” server and wipe all the data from it, then make conflicting updates while offline in two separate browsers. But when we spin up a new server, not only is all the lost data recovered, but every peer converges to the same update.
Woah, what is happening!?
Did we lose the overwritten update? No, because GUN uses immutable data structures and can preserve historical writes in the same way a timeseries database does. This feature will be available in upcoming releases, but not in the 0.2.x release.
Were you running a cluster to survive the failure? No, the only GUN server running was the one that crashed and got wiped. But ‘yes’, because GUN gets embedded into the browser! The tabs act as replica sets for whatever subset of the data they happen to contain.
How did they resolve the data, did you implement PAXOS? No, GUN uses an entirely deterministic conflict resolution algorithm that is a hybrid of Vector Clocks and Timestamps. Individually these techniques have vulnerabilities, but combined together create an optimal solution for most use cases.
To summarize, GUN is an open source realtime graph database written entirely in javascript and built using peer-to-peer algorithms. Making it surprisingly fault tolerant and easy to get started with. If you have NodeJS, just type `npm install gun`. We’ll have the 0.2.0 release out soon!
What is changing? Is anything breaking? Yes, we are renaming several methods. So it is important to follow the migration guide when we release. The good news is that the names should not change after that, and the chaining system has been improved. Most importantly, we’ll be adding SQL and MongoDB Query support which most of you requested.
Can I contribute? Yes, join the mailing list and chat with us on IRC to get started, we’d love it if you starred us and shared/retweeted us. Why should I, aren’t you a pet project? No, we’re VC backed and determined to build a better and easier database for you. That means we need your feedback.
What should I not use GUN for? Production deployments as we’re not yet stable, nor do we have any security, but hopefully we will be within a year. GUN is AP of the CAP Theorem with Eventual Consistency, meaning we probably are not ACID compliant. Don’t use us for banking or anything requiring centralization, or for data points that exist in isolation.
Thanks for the read! Check us out at http://gunDB.io/ and https://github.com/amark/gun soon, we’ll be adding a bunch of tutorials and documentation. Stuff is a bit sparse for now, but just wanted to give everyone the heads up about what is coming. And please, ask me anything!
