Duty called me away from the final day of the Dataversity NoSQL Now Conference in San Jose this week, but I was there for long enough to gain some insight into the issues facing today’s data geeks. And where else but a Silicon Valley NoSQL conference to find the ubergeekiest of them all?

Let’s start with the name of the conference. When was the last time you went to a tech conference centered on not doing something? Been to a “No Client/Server” conference lately? How about that “No Mainframe” conference? Sounds silly — but why is a NoSQL conference any different?

The problem, of course, is that we don’t really have anything else to call the rather motley assortment of vendors, technologies, and solutions that made up this conference. Name/value pair databases, columnar databases, graph databases, and all the associated hangers-on made an appearance. The common theme being not using SQL, even though no alternative query language has established itself as SQL’s successor.

But query languages were only the sideshow. In the center ring were discussions of specific data-related problems that traditional relational database management systems (RDBMSs) didn’t solve very well, and how various products blew the old guard RDBMSs out of the water at solving such problems. But again, there was no specific issue in everybody’s gun sights. Walking from booth to booth, I got the sense that everyone was offering different solutions for different problems. Excelling in niches trumped competing to become best of show. And in fact, nobody was saying they were the best at everything — a refreshing change from the days of SOA shows where all the big vendors touted kitchen sink suites that purported to do everything well, even though they were integrated at the PowerPoint layer.

But the most fascinating angle on this trend toward “niching” down product offerings, in fact, was the role the CAP theorem played. I’ve written and spoken about this theorem before, but this is the first conference I’ve attended where it came up several times. The CAP theorem, of course, says that any distributed system cannot exhibit basic availability, immediate consistency, and partition tolerance at the same time. You can have any two, but one has to give.

Some of the vendors required a bit of digging, but all their stories essentially focused on which of these three characteristics they were good at, which one they didn’t offer, and how they dealt with that weakness. But remember, the immaturity of the NoSQL market isn’t the problem. We’re stuck with the CAP theorem for better or worse, so now it’s time to figure out how to live with it.