They also stuck themselves on Cassandra 0.7 forever.
To reinforce that point, look at the data stax site or the last conference for some of the performance metrics comparing 1.2 to 1.0 and before. 

While you are worrying about the transport to cassandra, the project making things go faster. IMHO you will get more value for money ensuring you have timely access to the work other people do.  

Cheers

-----------------
Aaron Morton
Cassandra Consultant
New Zealand

@aaronmorton
http://www.thelastpickle.com

On 13/08/2013, at 12:12 PM, Robert Coli <rcoli@eventbrite.com> wrote:

On Mon, Jul 29, 2013 at 12:42 PM, Nulik Nol <nuliknol@gmail.com> wrote:
> Embedding the server will add *a lot* of complexity.

that's a conjecture one would come at first sight, but if you analyze
it , it is the opposite. Complexity increases with code, and
communication between processes (like via socket or memory buffer)
implies more code, so if you embed and call server objects directly,
your code will be simpler.

Leaving aside the somewhat nonsensical result of applying this thinking to computing in general...

... have you ever spoken with someone who has maintained such a large patchset to a database?

The people I spoke with at the Cassandra Summit who had forked Cassandra 0.7 so that they could remove thrift and get maximum performance from their patched version did in fact get improved performance. They also stuck themselves on Cassandra 0.7 forever.

Complexity is not just measured in lines of code, it derives in part from the maintainability of any given solution. In the open source world, this means being able to rebase your forked project to track/merge with upstream.

=Rob