Remember when you were a kid and you’d hear yourself recorded on an answer machine or on someone’s old handycam? Remember how cringe-making that was? Errr…that’s how I feel watching this. GigaOm was an interesting show and it was great to get to meet so many new vendors trying to make a difference in the next wave of big data analytics. The next three years are going to be fascinating to watch.

Talking of ‘watch’. Watch videos with the sponsors below. Mine is the first one. Feel free to skip over it.

As if you weren’t able to tell from our previous, riveting blog posts, chasker and I are at the GigaOm Structure Big Data conference. This morning, chasker was interviewed by GigaOm to discuss why Quest was sponsoring and I meant to record the whole interview with chasker in order to expose his lack of intellect. Unfortunately, I could not get close enough to hear anything and give a short overview of what we’re doing here…and expose my lack of intellect.

The discussion centered on what kinds of insight and knowledge the companies that these panelists work for were able to divine from incredibly disparate and “unstructured” data that they collect. While none of the data collected is in any way “new” to the business, individual or organization, the volumes certainly are.  Also, the statistical and pattern analyses that these appropriately titled data scientists use to put to use on these mountains of data is nothing short of amazing. Especially if you’re like me and the thought of anything more mathematically complicated than figuring out what the tip on a dinner bill makes me sweat a little bit.

Good Morning from GigaOm Structre – Big Data conference. If you’re from the West Coast like Andy and me our clock is showing 4.30am right now, and we’ve been up for a while setting up our table top. The hippie Toad for Cloud is already playing well for the audience; people stopping by and staring at the handsome fella.

There are around 40 sponsors here including splunk, Revolution Analytics, The New York Times, DataStax and EMC to name a few. There’s a packed agenda today, and I am most excited to attend a couple of sessions specifically – in about an hour there’s ‘The New Alchemists’, a panel of Data Scientists who are going to be talking more about their roles at companies like bit.ly, and Cloudscale. I’m also interested in ‘The Coming Revolution in Statistics’; the Chief Scientist of Revolution Analytics, Lee Edlsfsen, is presenting, and this is an area that we are looking at learning more about.

We’re really lucky at Quest to have some very smart R+D talent. Our head of R+D in Melbourne, Australia, came to the Bay Area last week for the Strata Conference and brought a couple of his top people. I got the chance to talk with them about what they’re up to around emerging roles and technologies.

No, this post is not a lament of parties gone by, where Acid was not just the drug du jour, but also flavor of music. Rather we’re in search of a better term to explain the new movement of databases.

Here are Quest when we are in meetings referring to the market we’re developing products for we use a lot of redundancy – ‘cloud databases, NoSQL, new data stores like Hadoop, Cassandra, MongoDB, open-source non-relational distributed databases’ – it gets EXHAUSTING!

We’ve grudgingly adopted the NoSQL label as it seems to be the one that is sticking for the moment, but rather than describe what these data stores are, it describes what they are not. Now we’re learning that some people in the industry are changing the term further to mean ‘Not Only SQL’. So we’re in search of a better term.

ACID (atomicity, consistency, isolation, durability) is a widely understood term, and when we think of it, we think of those predominant use cases for RDBMS; my bank withdrawals, transfers, credit card, mortgage payments etc. Non-ACID databases possess characteristics which don’t make them ideally suited for those use cases, but do make them a good choice for use cases where ACID compliance is not needed. In fact, the big brouhaha at Chase recently, where database issues made it impossible for customers (yep, I’m one of ‘em) to access their accounts, pay bills etc. was in part made worse because some of the types of data being stored, like customer web usage data, wasn’t necessary to be ACID-compliant. A non-ACID database would be ideal for storing that type of data.

So…non-ACID it is (or at least internally here until a better term comes along).

Jeremiah Peschka is joining Quest Software. Que? Oh yes…Jeremiah is joining Quest Software. Read about it here, and here. But hold on Christian…you haven’t learned diddly from the grand experiment! You are meeting your own definition of insanity sir. Au contraire…au contraire. Yes, Jeremiah is joining us, but it isn’t to take over Brent’s job, just his budget.

As I have been talking about lately with anyone who will listen (my 4 year old daugthers seem to be the only ones listening and even they listen to me for about 30 seconds before tuning out) we have a tremendous opportunity in the non-relational distributed database world to build and educate the community. We wanted someone with a passion for community, a passion for RDBMS, a passion for development, and a passion for learning about new technology. Fortunately, we did not need to look. Brent, Andy and I had already been talking about how we might evolve the role as Brent was moving on to pastures new and Jeremiah’s name came up. Then, one morning, as if by magic (although maybe suggested by one Mr Ozar – don’t know???) a hilarious email appeared in my inbox. It was from Jeremiah and it listed out why he would be right for the role and why he would be different from Brent. I was laughing hard. To be honest, if the email had been about why Jeremiah would be same same we would have gone no further, but he laid out what he could bring to the party, and we had plenty of chips but no dip, so we were hooked.

So, over the course of the next few months we look forward to working on and unveiling our evolved strategy for servicing the community. Don’t fret that Jeremiah will be turning his back on the SQL community – won’t happen; he’ll keep one foot firmly in that camp, but don’t be surprised if he starts trying to talk you in to giving Cassandra, MongoDB, HBase or Hadoop a whirl. Don’t be surprised when he turns PASS into the largest NoSQL conference in the world.

Ok…had you there for a second right?

This morning we announced the launch of two new sites; siblings to sqlserverpedia. You can read the press release from this morning here.

SQLServerPedia has exceeded every metric and every expectation we had set (we like to keep our standards extremely low so we always leap over the bar ), so now it’s time to see if the experiment works in other domains. We’ve decided to tackle a bit of the old and a bit of the new to see how different communities respond.

OraDBPedia is a knowledge-base aimed at the Oracle database crowd (bet you never guessed that right?). This is an area that Quest has a lot of thought-leadership in, and a long history. It’s where we made our name, and Toad is still the most widely used tool in that space. However, at first glance the characteristics of the Oracle community are different to the SQLServer crowd; users don’t seem to be as prevalent on Twitter and there isn’t the volume of independent blogs that we are used to seeing in SQL Server. Oracle themselves are much more of a closed community-type company than Microsoft, so maybe that’s why. Anyway, we look forward to learning more and reporting back our findings.

CloudDBPedia is a knowledge-base aimed at the non-relational world (cloud databases, NoSQL databases, Hadoop). We want to become the thought-leaders in this new world, as we are in the RDBMS world. Now, the characteristics of this community are absolutely fascinating – it is all you would expect of a community that is growing in a world of Twitter, Tumblr, Facebook – so the learning curve we experience here will be steep and we’ll have to respond fast if we are to succeed. We look forward to the challenge and to keeping you apprised of lessons learned the hard way.