

VoltDB - in memory, ACID compliant, partitioned, SQL database - bensummers
http://www.voltdb.com/product

======
superjared
Early adopter signup gives access to the source, which is licensed under
GPLv3. However, there is a binding Beta agreement which states that I may not
redistribute the code/application.

 _The VoltDB software is being published as open source software under the Gnu
Public License V3. In other words, as Early Release program members, you now
have access to the source files for VoltDB and the development tools for
browsing the source code and the current issues lists.

Please note, however, that the Beta agreement is still in effect until VoltDB
is officially available. So we ask that you not redistribute the source or
binaries beyond your own use at this time._

Is this legally enforceable?

~~~
sad
Legally, probably not. They aren't demanding that you not redistribute, just
asking. And asking politely. They are banking on the good nature of people.
Good for them! And us.

~~~
cabalamat
If they don't want people to redistribute the code, why on earth are they
GPL'ing it?

~~~
pinko
I can't speak for them, but in our case we had major users who required open-
source (mostly European govt. projects).

All our developers wanted to just post the source online and be done with it,
but our boss had security concerns he wanted us to address first -- so in the
meantime we gave people who needed it GPL'ed copies, and asked them politely
not to redistribute until we were ready.

------
xtacy
I don't understand how they could avoid locks. They say that each replica runs
independently and hence that avoids locking; what about write updates to the
same object from different clients? That would need locking of some form at
some level.

They should also explicitly discuss the failure models for which they're
guaranteeing Durability. If you're scaling to "web-scale", and running this db
in a data-centre, then, a single failure would wipe out a rack of machines.
Coordinated failures are not uncommon in data-centres. What about those?

~~~
itistoday
From their whitepaper:

 _"Conventional databases experience disk and user stalls within transactions.
Rather than let the CPU be idle during the stalls, those DBMSs interleave SQL
execution from multiple transactions during the waits so the CPU is always
busy. This is what requires much of the complex latching and locking overhead.

VoltDB doesn’t experience user stalls (since transactions happen within stored
procedures) or disk stalls (because VoltDB processes data in main memory).
Therefore, it is able to eliminate the overhead associated with multi-
threading (latching) and locking. Each VoltDB execution engine is single-
threaded and contains a queue of transaction requests, which it executes
sequentially—and exclusively—against its data. Elimination of stalls and the
need for locking and latching overhead and allows typical VoltDB SQL
operations to complete in microseconds.

For single-partition transactions, each VoltDB engine operates autonomously.
For multi-partition transactions, one engine distributes and coordinates work
plans for the other engines. VoltDB assumes that an application designer can
construct a partitioning/cloning scheme and a transaction design that makes a
large majority of the transactions local to a single virtual node. Many common
applications such as order-fulfillment, software as a service (SaaS), Web 2.0
and trading systems have this property."_

[http://www.voltdb.com/_pdf/VoltDBTechnicalOverviewWhitePaper...](http://www.voltdb.com/_pdf/VoltDBTechnicalOverviewWhitePaper.pdf)

~~~
stingraycharles
That still doesn't completely answer the question how it avoids race
conditions and the likes without locking. Assume I'm executing multiple long-
running transactions, each hitting and modifying a lot (millions) of different
objects. How are race conditions avoided in this case ? One engine that
distributes and coordinates work plans for the other engines sounds nice, but
does this essentially mean that only one of these transactions is able to run
at the same time, even when they could be running concurrently when using
locking?

~~~
wmf
VoltDB is designed for short transactions that each touch one row, so you
should expect pretty poor performance for long-running transactions.

------
braindead_in
I guess in memory means that it never writes data to the disks. So what
happens when the machine reboots?

~~~
tlack
In-memory DBs can take a lot of excellent shortcuts but I have to wonder if
their usability is limited. After all, I'd think most interesting data sets
end up quickly eclipsing the available RAM in most off the shelf/affordable
servers.

~~~
cx01
Keep in mind that VoltDB targets the OLTP market, where datasets tend to be
not that large. If you build a small cluster of 50 nodes with 256GB RAM each,
you have about 4.3TB of storage (with a replication factor of 3).

------
st3fan
Have to fill in a form to see a whitepaper. Yeah whatever.

~~~
Pahalial
They're just gauging interest and making sure to get emails they can push
adoption to later, it's a classic sales technique. Don't hate.

Regardless, the links they send are open:

VoltDB product overview: <http://www.voltdb.com/_pdf/VoltDBOverview.pdf>

VoltDB Technical Architecture white paper:
[http://www.voltdb.com/_pdf/VoltDBTechnicalOverviewWhitePaper...](http://www.voltdb.com/_pdf/VoltDBTechnicalOverviewWhitePaper.pdf)

------
ck2
So, how fast does it run ALTER ?

------
sovande
GPLv3, wonder what their business model is.

