How does the Eve database compare to GunDB, PouchDB or RethinkDB?

[Zubair Quraishi]

I am playing around with  GunDB, PouchDB and RethinkDB so I was wondering if they were considered and dropped for any reason?

[Liron Shapira]

Eve is fundamentally different from the DBs you mentioned. Many of Eve's ideas come from this research paper: Dedalus - Datalog in time and space

One of Eve's building blocks is the "logic programming" behavior from Prolog/Datalog/Dedalus, which hasn't yet caught on in either mainstream programming or mainstream databases (including the ones you mentioned), but might now be due for a moment in the sun. Logic programming has great properties that make it easy to reason about your program's behavior, and also about your distributed database's behavior.

Example of a killer feature

I'll highlight one unique feature of Eve that I'm personally passionate about: monitoring deduced values. You might also call this "database-level Functional Reactive Programming (FRP) semantics". Let me explain...

First, let's talk about monitoring ordinary values (as opposed to deduced values). Say you have a typical SQL database. When you do a simple lookup like `SELECT id, firstName, lastName, job FROM Users WHERE id = 'jsmith'` and you get back an unaltered record like `[jsmith | John | Smith | sales manager]`, you're getting back ordinary values. It's pretty standard to track changes to ordinary values by monitoring the database's oplog, and it's especially easy to do if you use a "realtime database" like GunDB, RethinkDB or Firebase.

But now let's talk about monitoring *deduced* values. When you do a fancier query like `SELECT count(*) FROM Users WHERE job LIKE 'sales%'` and get back the value `13`, that's a "deduced value" because `13` isn't part of your data per se; rather, it's logically implied by your data. Aggregations like `count` are a well-known example of deduced value, but any (composition of) pure functions of your database's ordinary values define deduced values.

So now you understand what I mean by "Eve has a unique ability to monitor changes in deduced values".

If you wanted to monitor a deduced value without Eve, you can get by if it's a simple case, by using a DB feature like "computed indexes" or "materialized views". But in the general case of arbitrarily-complex deductions, there is currently no popular DB that can efficiently propagate value changes and let you react to them.

If you're skeptical that "monitoring changes in deduced values" is much-needed functionality, consider that it's one of the hottest things catching on for application-layer state, in the form of MobX. Eve is bringing MobX-like functionality to the database level (and all levels).

By the way...

The rest of this isn't directly related to your question but I think speaks to the bigger picture of Eve...

Say you agree that at the database layer, Eve is a reasonable alternative choice of database.

Say you agree that for the API layer, Eve is a reasonable alternative to GraphQL.

Say you agree that at the application layer, Eve is a reasonable alternative to Flux/Redux/MobX.

Say you agree that for rendering layer, Eve is a reasonable alternative to the DOM API, or React render functions, or Angular render templates.

Say you agree that for configs, Eve is a reasonable alternative to environment variables and YAML files.

Say you agree that for logging, Eve is a reasonable alternative to event databases and log files.

Say you agree that for event-based I/O, Eve is a reasonable alternative to lexically-scoped event objects.

Then how about just picking Eve for all these layers?

Look how much value we got by having JSON be a standard glue format. JSON makes things feel easier right? And that's only a serialization format.

I think having Eve as a uniform choice of "glue format" is going to make a lot of things similarly feel easier.

[wuzz...@gmail.com]

Surprised nobody’s asked about Datomic/DataScript, which are very cool and somewhat popular EAVT stores in Clojure/ClojureScript/JavaScript. Learning DataScript’s query system is helping with the Eve learning curve!

[Zubair Quraishi]

Liron,
Firstly, thanks for an amazing answer!!!! So my understanding of what you said is that the Eve database can deduce values in an efficient way in real time, like a super charged "materialized view", which no other database can do, is that correct?
Zubair

[Liron Shapira]

Yep exactly.

I recently wrote a blog post about how we need a "denormalization engine" aka database with supercharged materialized views, so I was happy to discover Eve a couple weeks later.

https://hackernoon.com/data-denormalization-is-broken-7b697352f405

[Zubair Quraishi]

Yes I read your article some weeks ago, and loved it actually. I had know idea that you are excited about Eve :)

[Joseph Gentle]

Hah I've been working on making a database along similar lines the
last month or two. I think of it as basically the database version of
storm (or, what you'd get if you broke a normal database into small
pieces and connected them via ZMQ or something like it).

I wrote a blog post about it a couple of months ago:
https://josephg.com/blog/composing-databases/

-J

> --
> You received this message because you are subscribed to the Google Groups
> "Eve talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to eve-talk+u...@googlegroups.com.
> To post to this group, send email to eve-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/eve-talk/6be92468-7620-4915-a165-2d63f2991090%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.