In-Depth
Kickfire Targets Underserved Users in Crowded Analytic Database Market
Analytic appliance specialist Kickfire seems happy to play in the sub-6 TB arena. It's where most of the new projects are sprouting, officials argue.
When database appliance player Kickfire Inc. launched 18 months ago, it had its work cut out for it.
The Second Wave of analytic database systems -- i.e., the Columnar Invasion -- occurred between mid-2007 and the first part of 2008, and although the market has since produced other entrants, it likewise hasn't lost any players.
The upshot: The analytic database arena is crowded. Very crowded. That can make it hard to get a word in edgewise. It helps that most analytic database vendors have refined their messaging or identified market niches in which they believe they can be competitive.
Kickfire is no different. Its pitch -- to a notionally under-served market (the hundreds-of-gigabytes up to 6 TB segment) -- boasts hardware special sauce (in the form of an FPGA SQL accelerator). It seems intriguing, if not compelling. Although almost all analytic database players are happy to compete in the sub-TB region, most trumpet double- or triple-digit-terabyte implementations. What's more, outside of Netezza Inc., most analytic database vendors have moved away from proprietary -- or not-completely-off-the-shelf -- hardware underpinnings.
Richard Nieset, vice president of sales and marketing, says Kickfire's FPGA-based add-in card -- which it calls a Query Processing Module (QPM) -- and "concentrated" market focus help to differentiate it from the rest of the analytic database pack.
"[That] co-processor chip, which is part of our intellectual property … [does] about 80 to 90 percent of the SQL algebra, if you will, on-chip. That's where we get a lot of our speed. That's one reason why we feel none of our competitors can compete with us [on performance]," he comments.
Few analytic database or appliance entrants seem to want to discuss anything but high-end data warehousing or (more recently) advanced analytics. Nieset, on the other hand, says Kickfire likewise excels in less rarefied scenarios -- such as specialized operational or production reporting.
At what he positions as an "accessible" price-point (at around $64,000-per-TB, putting it on par with the $64,000-per-TB off-sheet prices of some rivals) -- the Kickfire appliance can address a wide gamut of BI and DW needs, Nieset maintains.
"This [Kickfire appliance] can also be effective at running specialized reports. It can be good for business intelligence in a lot of different ways, so it's kind of targeted at the business intelligence reporting and analytics market," he asserts.
Although it's a product of the post-Columnar Invasion, the vanilla Kickfire appliance -- unlike many newer market entrants -- is not an explicitly columnar solution. That's poised to change, Nieset indicates.
"We're also working on a column-store database that's built over MySQL, so it appears to the outside world as a MySQL database, using the same commands and syntax, but underneath the covers it's actually a column-store," he explains.
Kickfire's hybrid-columnar implementation is its own concoction, according to Nieset. "It's our own design. We're basically intercepting the incoming SQL and then figuring out what we can optimize in our own chip and what we run in regular software. We combine at the end and hand the results back to the users.
Kickfire's appliance architecture is likewise different from its competitors, be they column- or row-based. Although the base Kickfire appliance can be outfitted with up to 32 GB of RAM, its QPMs -- which plug into the base Kickfire appliance via a PCI-X expansion module -- can be populated with up to 256 GB.
Given the sizes of the warehouse configurations that most Kickfire customers start with -- typically from 50 to 300 GB, says Nieset -- a customer could potentially load all of their user data into QPM memory.
On the other hand, Nieset concedes, Kickfire's MySQL engine isn't as mature, fast, or full-featured as proprietary offerings such as Teradata Warehouse or Oracle 11g. Kickfire allocates at least a portion of its hardware special sauce to offset the limitations of MySQL.
"In the data warehousing analytics domain, MySQL is … immature relative to things like an Oracle [database] would have. The maturity is not there, so consequently somebody that's coming from a more mature Teradata- or Oracle-type of background into MySQL will go, 'What, it doesn't have this? How can it not have this?'" he acknowledges.
"On the other hand, the advantages [of the Kickfire implementation] are great enough that they can quickly get around that. You can do whatever you want to do. Yes, there's a certain amount of manual intervention that you need to do to get around some [feature limitations], but for most of our customers, the advantages we bring to the table far offset the limits [of MySQL] for these kinds of projects."
The salient point, Nieset contends, is that most Kickfire uptake is of the newborn kind. "The majority of interest in Kickfire is coming from new projects," he explains. Ideally -- from the perspective of many enterprise IT executives (or their CFOs) -- new projects would be based on open source software (OSS) databases.
At the same time -- and from the perspective of an enterprise IT chief, at least -- OSS databases such as MySQL lack some of the bells, whistles, or performance of their proprietary competitors. It's the kind of dilemma that tends to imperil the success of new projects, Nieset maintains.
"New projects don't want to start with a proprietary database. They want to start with an open source database," he argues. "It's kind of like, 'I know this application isn't going to run well in Oracle. It's 100 GB, and it's pretty important to my business, but I'm not going to go to the trouble of setting the hardware up and buying new licenses and spending a ton of money on capital expenses.'"
It's precisely this kind of need that Kickfire is designed to address, Nieset concludes. "If they start on an open source database, they can potentially run into enough performance problems that the project runs out of gas. We bridge that gap. Most of our prospects start with 50 or 100 or 300 GB databases, initially. They're already hitting a wall. We're able to offer them a plug-and-play solution for [their performance problems]. We're plug-and-play, we're open source -- we're based on the same MySQL [database] they started with -- and we offer better performance than proprietary [databases]."