You thought you wanted to use a document store until you realized that redis+postgres was actually what you needed :P

this article is full of lies. thats all i can say.

Thanks guys ;)Glad the configs and blog posts helPed you.

It currently supports multi-tenant and single tenant, you choose when you set it up.

Currently the multi-tenancy is based on locked down unix users and permissions and other system hardening, pretty much same approach Heroku uses so you judge whether that's multi-tenant or not. We are looking into lightweight containers like lxc and friends for another implementation of the multi-tenancy.

None of the code comes from Heroku at all.

We can take any .war file that runs on Tomcat, even jruby apps. Not just spring.

I really think you should make this clear. We're a Java shop, but we use all sorts of frameworks; play, spring, homegrown, but they all build to .war.

This is an interesting product to me, but from the marketing material it's not obvious...

I agree and I'm working with marketing folks to make this stuff more clear. There are just so many details to get a release like this out the door that some things didn't get as much attention as they deserved. But your point is well taken and I'll try to get the message cleared up as it is pretty cool IMHO.

Also look for some more technical deep dive blog posts on my blog by tomorrow at http://brainspl.at where I will clarify a bunch of this stuff.(right after I get some sleep;)

Which would mean that Clojure apps would qualify as well - now that might be interesting. We're running our apps on Amazon EC2 right now, managing Redis ourselves.

Maybe you should mention Grails, after all, VMware does own it.

It doesn't care about virtualization layer, runs on raw hardware too.

When was the last time Heroku accepted a pull request from you? ;)

Hey there, Ezra! :)

Agreed...the open aspect of it and how it morphs through the community will be very interesting. Looking forward to it.

As a follow up, my initial response came out a bit more snarky than I intended. Sorry about that.

No worries and I am good friends with the Heroku guys and I fully give them props for lots of the pioneering ideas in this space.

This project means to take it further though and be one everyone's cloud operating system, the Linux of cloud OS's if you will. It will live or die based on the open source can build around it. I fully intend to try to build this community and nurture it so this project flourishes. The personal PaaS angle is what I'm most excited about. Whatch for my technical blog posts tomorrow after I get some rest for more info...

I call BS on rabbit pushing 100K messages per core and I really like rabbit. But it is no where near 100k messages/sec per core.

AMQP does have extra capabilities and is a good messaging system and has advanced routing features, but you need to learn what exchanges, queues and bindings are and how they relate before it is useful.

I've used rabbit in production on multiple systems and it is still running on some of those. But I have switched to redis for most of my messaging needs because of the built in data structures and persistence. It makes it a much more versatile server and it is much easier to admin and much more stable. Rabbit is too easy to push over when you run it out of memory.

But I had to chime in and refute your 100k messages per core on rabbit. 20k maybe with the java client, more like 5-7k with a ruby or python client.

I can still get 80k/sec with a ruby client on redis.

The two servers are very different, redis is a swiss army knife of data structures over the network, that is why it is so useful. AMQP and rabbit are targeted more at enterprise messaging and integration where raw speed doesn't matter as much as complex hierarchies of brokers and middleware.

We do 120K messages per core per second with QPid (RHM), which includes an AIO transactional journal and multi-master clustering. Woo. :)