

Vedis: An embeddable Redis - StavrosK
http://vedis.symisc.net/

======
networked
How does this compare to rlite
([https://github.com/seppo0010/rlite](https://github.com/seppo0010/rlite))?

~~~
StavrosK
Oooh, rlite also looks great. Have you used it?

~~~
networked
Not yet. I would like to benchmark it against both SQLite 3 and key-value
stores like MDB ([http://symas.com/mdb/](http://symas.com/mdb/)) some time.

~~~
StavrosK
I don't think comparing against SQLite would be meaningful, SQLite is full
ACID with synchronous writes.

This post looks interesting:

[http://charlesleifer.com/blog/alternative-redis-like-
databas...](http://charlesleifer.com/blog/alternative-redis-like-databases-
with-python/)

~~~
networked
Vedis is called an ACID database on its website and rlite is called
"transactional" in the read-me, so I assume that, like SQLite, by default they
sync at the end of each transaction. Even if this weren't the case, though, I
think the comparison would still be appropriate. Any embedded database,
regardless of its stated use case, is in direct competition with SQLite
because the latter dominates the market (and for good reason!).

Looking for existing benchmarks of this kind I have found one that compares
Vedis, Redis and SQLite: [http://charlesleifer.com/blog/completely-un-
scientific-bench...](http://charlesleifer.com/blog/completely-un-scientific-
benchmarks-of-some-embedded-databases-with-python/).

~~~
StavrosK
> Vedis is called an ACID database on its website

The "D" means it should fsync on writes, yep.

> rlite is called "transactional" in the read-me

Transactions in no way imply durability.

> Any embedded database, regardless of its stated use case, is in direct
> competition with SQLite because the latter dominates the market (and for
> good reason!).

If you mean that you should compare them, then I agree. If you mean that you
should benchmark them against each other, then no, you're going to get junk
results because they're very different. That benchmarks seems to have fallen
in that trap, as it seems to be comparing durable with non-durable datastores
with no mention of the persistence setting.

~~~
networked
>Transactions in no way imply durability.

I don't think that's true. Transactions are commonly defined as durable (e.g.,
in [https://msdn.microsoft.com/en-
us/library/aa366402%28VS.85%29...](https://msdn.microsoft.com/en-
us/library/aa366402%28VS.85%29.aspx)). The term "transactional database" is
used synonymously with "ACID database".

>If you mean that you should compare them, then I agree. If you mean that you
should benchmark them against each other, then no, you're going to get junk
results because they're very different.

You're right. One _could_ benchmark a non-ACID datastore against SQLite but
only if each ran in an in-memory database mode.

>That benchmarks seems to have fallen in that trap, as it seems to be
comparing durable with non-durable datastores with no mention of the
persistence setting.

I agree with you per the above, however, the results from SQLite and Vedis in
particular appear to be meaningful to compare.

Edit: One thing I've just noticed about Vedis is that it is dual-licensed
under the Sleepycat license and a paid commercial use license. The Sleepycat
license is a strong copyleft license that requires that you ship the code to
"any accompanying software that uses the DB software". It's something to have
in mind if you want to use Vedis commercially. By contrast, rlite has a
2-clause BSD license.

~~~
StavrosK
> I don't think that's true.

I think it's largely a matter of interpretation. To me, transactions imply
atomicity, isolation and consistency, but not durability (e.g. in-memory
datastores can still support transactions). I can see your point, though.

> One could benchmark a non-ACID datastore against SQLite but only if each ran
> in an in-memory database mode.

Yep, or you can just turn fsync off. This is an option in most databases, to
trade performance off for durability.

> the results from SQLite and Vedis in particular appear to be meaningful to
> compare.

Yep, Vedis seems to fsync after every commit, so I think you're right.

> requires that you ship the code to "any accompanying software that uses the
> DB software".

Ah, damnit, that's prohibitive. I didn't notice that, thanks, I thought they
only required the source for modifying Vedis itself. rlite looks better, I
think.

