H-Store is now VoltDB
I’ve always honored more of an NDA about the H-Store project and its commercialization than I really felt obligated to, given how freely information was being bandied about to others. I’m still doing so. 🙂
But I think I’ll at least say that the H-Store project is now named VoltDB. The VoltDB website names two individuals — Mike Stonebraker and Andy Palmer — both of whom are founders of Vertica. Job listings on the site are for field engineer and trainer, but not developer, so that suggests something about the project’s/product’s maturity level.
If you have an extreme OLTP need, you should talk to VoltDB. If you don’t have access to Mike or Andy directly, I can hook you up with a key VoltDB marketing/outreach guy. Price may not be as much of a barrier as you’d initially fear.
If anybody from VoltDB wants to be less cloak-and-daggery and say more in the comment thread, I’d be pleased.
And yes — an open-secret working name for H-Store/VoltDB was, for a while, “Horizontica.”
Comments
15 Responses to “H-Store is now VoltDB”
Leave a Reply
Does this mean both of the founders donot believe in Vertica any more?. Vertica and Streambase have not made it yet and they start a new company. Looks funny to me.
Oh, fun. Another anonymous Vertica- or Aster-bashing post containing a first-person pronoun! (Vertica in this case.)
Your answer, by the way, is “no”, unless they’ve done a very good job of fooling me.
Curt, you are fooled easily, all it takes is $$$. just re-read your posts from the last few years and it’s clear you “parrot” what clients pay you and bash those who don’t. take special interest in your DATallegro regurgitations…they are almost comical now that the truth is out
I’m not interested in having detailed accountability discussions with somebody who hides behind anonymity his/her/itself.
I wish people would limit criticism to the content of your posts.
I read the H-Store paper several times. After the first reading I thought it was silly. After the second reading I got it. There was at least one thing in H-Store that they really needed to fix — using residence in RAM on several machines rather than persistence on disk on several machines to achieve k-safety. But they will be able to achieve amazing numbers on realistic workloads.
In response to the first comment, I think the evidence is quite to the contrary. Mike Stonebraker has suggested very strongly that “one size does not fit all” for database management systems anymore. Vertica, Streambase and H-Store (now VoltDB) attack different problems. Vertica isn’t an OLTP database and VoltDB isn’t for data warehousing. For me, the interesting problem to solve will be how to get data from an OLTP database (say, VoltDB) into a data warehouse database (say, Vertica) to address both the operational and “informational” requirements of most businesses today.
Never underestimate Mike Stonebraker’s insights. With Ted Codd and Jim Gray gone, Dr. Stonebraker (along with the remaining original System R researchers) is one of the world’s foremost experts on database technology.
Coincidentally, Vertica just gave me a heads-up on something specific Stonebraker plans to do for them. Details are confidential, but I figure it’s OK to mention the general point … 😉
During discussions I had with VoltDB (as it is now called) engineers, I suggested how useful it would be to have a way to migrate OLTP data gradually out of VoltDB and into Vertica, as particular items of data cease to change and become archival in nature. I suggested this to them and it turns out that they had been thinking along those lines already. None of this means anything about future product plans or anything, just that they do know about that idea.
[…] technology. There also are strong similarities to the MPP in-memory row store project H-Store/VoltDB, although I don’t know whether Plattner would go so far as to adopt the H-Store view that all […]
[…] One obvious concern about Groovy’s approach is RAM cost. If you’re interested in the Groovy SQL Switch, you probably have a large transaction volume, in which case you probably also have a fast-growing database. Absent some kind of manual partitioning, the Groovy SQL Switch currently requires you to have enough RAM to hold that in its entirety. The same comment, of course, is probably true about VoltDB. […]
[…] option for OLTP performance and scale-out is of course memory-centric options such as VoltDB or the Groovy SQL Switch. But this client’s database is terabyte-scale, so hardware costs […]
Scale out OLTP products has been around for a while as “object” data management products, extensively used in trading environments (where VoltDB is positioned) offering memory only storage, variety of replication, partitioning strategies and varying levels of concurrency control, all designed to tackle the high scale and reliability problem for OLTP data. GemStone recently announced a SQL centric horizontally partitioned memory oriented product called GemFire SQLFabric (http://community.gemstone.com/display/sqlfabric/SQLFabric).
[…] often-unspecified — “overhead” are interesting to view through the lens of the H-Store/VoltDB project. Mike Stonebraker et […]
[…] VoltDB is the main exception that jumps to mind. […]
[…] Akiban or VoltDB, Clustrix makes database appliances. The Clustrix software seems to assume a Clustrix […]