Thanks for the reply Rob,

As to cherry picking, I wasn't calling out anyone in particular, but the thread 
in general. I believe some of our disagreement involves around the statement 
"MongoDB, which falls into the same class of database as U2.": MongoDB is *not* 
an enterprise class database. As per Charles Shaffer post, would you honestly 
use MongoDB for his system? I wouldn't. You would either go with a major SQL DB 
or an MVDB (such as a U2 system). As I and others have noted, U2 gives you a 
unique value proposition in that it generally has faster change turn-around,  
cheaper associated costs and stability of platform (it will still be fine in 20 
years without major architectural changes). MongoDB just doesn't fit into this 
realm. It isn't enterprise class; it doesn't have the maturity to provide the 
guarantees needed in serious enterprise systems, even if only for the mere fact 
it hasn't been around long enough to prove it. As to FourSquare, please re-note 
the link to FS's 11 hour outage caused by MongoDB as an actual example. Can you 
imagine Bank of America having an 11 hour outage on all money transactions and 
how much money/customers they would lose? People have been conditioned to 
accept website outages from time to time. No-one is going to die because FS is 
down for a day. Other things in life are not forgiven/forgotten so easily. 
Emergency systems run on U2. I would consider myself insanely negligent if I 
convinced those emergency services to drop U2 and replace it with an immature 
(even if exciting) database such as MongoDB.

I cannot really comment on your issues with UniData, not knowing when or what 
they were. We ran UD at a Bank and out of our 20+ systems (most on MS SQL) it 
was by far the most stable with the least down time. It had to be, lest it put 
us out of business. 

U2 does not (and cannot) target EVERY market out there. Comparing it to other 
databases outside of the its core markets and saying "MongoDB destroys U2 in 
every single aspect.  And it's free" ( is a catchy, yet 
ultimately flawed statement.

I don't think anyone would argue that 'Big Blue' and 'Agile'  are the wine and 
cheese combination of the tech world. Please remember that U2 is now Rocket U2, 
not IBM U2. Rocket Software is an amazingly agile company in comparison. How 
long did it take them to release DataVu? Also remember that in the "company 
scale" of time U2 hasn't been with Rocket for that long. Take into account ramp 
up time for a new working environment, complete office move, rebranding of all 
products and documentation when determining how sluggish U2 is. Expect more 
developments to come out quicker. There are some exciting changes coming down 
the pipes that will address some of the issues people have raised in this 

UniObjects (COM) is an ancient interface. Don't forgot that there is now EDA, a 
SOAP-based web-service provider and a RESTful web-service provider (in beta).

Better resources: more is coming. U2DevZone is up, it is now open (no sign in 
required anymore) with articles, video tutorials and podcasts. You can take 
this as a solid indication that the folks here are committed to providing 
material that makes U2 a more attractive option.

Yes, times are interesting in the database world right now. There has not been 
this much attention and diversity for as long as I can remember. I'd love to 
see you (and everyone else) at U2U next year, meet some of management & 
engineering and see what is happening in the U2/MV world and maybe even provide 
some insight into what keeps you interested in the MV world and what doesn't. 
Obviously there is something in there that interests your technical mind for 
you still to be posting on this list. :)


PS: Thanks also to all those that sent direct replies to me. If I haven't got 
back to you yet, I will endeavor to do so next week. 

-----Original Message-----
[] On Behalf Of Rob Sobers
Sent: Thursday, July 14, 2011 4:41 PM
To: U2 Users List
Subject: Re: [U2] Why Pick U2?

Hey Dan,

Great response! Thanks for chiming in.  Let me address some of your points.

"Cherry-picking individual features from one database to compare them, then 
cherry-picking from completely different database when counter-points are 
raised is not exactly a technically sound (or fair) way to do comparisons."

You're certainly right, but that's not I'm doing.  I believe the only direct 
feature comparison I made was to MongoDB, which falls into the same class of 
database as U2.

Besides, the discussion isn't purely about technical capabilities (though they 
certainly matter and U2 has been sluggish with new feature development) as much 
as it is about the overall value proposition.

I'm not trying to be a troll, or incite the folks that love U2, or call out 
Rocket.  As a long-time U2 user, I'm simply making an honest and blunt 
statement that I  would not pick U2 as my database on a new product, and I'm 
curious to hear if others can argue in favor of U2 given the rise of lower 
cost, popular alternatives in the same niche.

I think it's extremely hard to argue in favor of U2 give its price tag and 
underdeveloped ecosystem.

For *me personally*, when I'm contemplating which technology to use on a new 
project, some of the things that are very important are:

1.) Mainstream adoption.  If I have a wacky problem with U2, I basically 2 
places to go: Rocket support or this list.  That's it.  You can't overlook the 
beneifts of using mainstream technologies.

Again, when I was working with U2 full-time, we were consistently finding core 
bugs in U2 that hampered business, and it would be months on end without any 
progress from IBM.

(If you don't believe me, try using some of the SQL features in the latest 
build of UniData.)

2) Ecosystem and accessibility.  Are there APIs, language bindings, and 
libraries available, or am I limited?

I brought this up on another thread -- what if I need to parse JSON in 
UniBasic, or I want to generate a PDF document?  There simply aren't a wealth 
of UniBasic libraries available like there are in Java, Ruby, .NET, etc.

This can be partially addressed by making U2 more accessible from modern 
languages or at the very least, provide better guidance and resources to help 
the users create their own.  Right now all we have is UniObjects, which is 
kinda crappy.

c) Cost. U2 is expensive for what you get.  That might have been justified in 
the 90s, and 2000s when theren't were viable MV alternatives.  But now there 
are alternatives.  Free ones.

It's easy to say that "U2 has been around for a while, so it must be reliable 
and enterprise grade."  But I can't tell you how many times I've had to take my 
UniData system down and run "guide" because of database-level corruption.  
Anecdotal yes, but so are your claims against MongoDB.  I believe Foursquare 
still uses it, and I'm going to venture a wild guess that their load is far 
greater than any single U2 customer's.

I also don't buy the case for writing your business logic in what is basically 
a hamstrung stored procedure language.  This isn't necessary to get the 
benefits you're describing.  As long as you properly tier your code so that 
your business logic is separate from your presentation layer, it doesn't matter 
where the code lives physically.

SQL access in U2 has been a pain point for me in the past, but maybe I was 
doing it wrong or things have changed lately.

The idea of using U2 as in in-memory cache is an interesting idea.  I wonder if 
anyone has done that in production.

Anyway, thanks for the excellent and thorough response, Dan.  You make some 
great points and you're an extremely bright guy and Rocket is very smart for 
bringing you aboard.  I look forward to seeing what's coming, but as it is 
right now, U2 just isn't an option for me.  You've got your work cut out for 
you, though, as the competition is moving fast. :-)


U2-Users mailing list

Reply via email to