db.* proves it’s a database survivor

71

Author: Mary E. Tyler

The open source database db.* (pronounced D B star) has survived proprietary origins and the dot-com bust to find new life as an open source product.

db.* has been in the market for more than 20 years. Originally, it was a proprietary product called dbVista developed by a company called Raima. During the dot-com boom, it was acquired by a company called Centura and released into open source under a modified Mozilla
license. Centura spent millions of dollars to bring the code base up to standards, including overhauling the documentation. However, in 2001, Centura dot-bombed and went belly up, leaving db.* orphaned. Unlike an orphaned proprietary product though, another company could — and did — step in.

“It’s a shame to let this kind of investment and this kind of effort by top notch engineers go to waste,” ITTIA’s president Sasan Montaseri says. “We brought [db.*] back and
introduced it to the market and we have been successful with that.” In fact, ITTIA counts [international telecommunications giant] Marconi, JC Penney, Moody’s Investors, and Ohio State University among its clients.

While db.* may be an interesting alternative, it’s no market leader. According to Noel Yuhanna, senior analyst at Forrester Research, db.* remains a small player in a specialized niche. “db.* is not on our radar screen,” says Yuhanna. “MySQL and PostgreSQL dominate
the space. For the embedded market, open source databases SleepyCat and Berkley DB are more common.”

But ITTIA’s Montaseri claims db.* has some technology advantage over proprietary competitors that depend on languages like SQL to get information from the database. Most databases use a relational model, which relies on a set of indexes to get to the records. “Accessing those indexes takes its own time,” says Montaseri. db.* uses a hybrid of a relational and a network model. Analyst Yuhanna confirms that with the hybrid model db.* uses, the designer can choose the indexes used, lessening resource-intensive I/O calls and resulting in a performance boost. However, since this approach forces db.* to abandon standards like the SQL language, it lessens the appeal of such a tactic.

Montaseri says another major advantage is db.*’s small size. “On [embedded systems], it’s the footprint. You want to have the footprint as small as possible,” explains Montaseri. “With other databases, because they use other APIs and other methods such as SQL the footprint is much higher.”

“One of db.*’s benefits — and one of its disadvantages — is that it was developed for intelligent developers,” Montaseri says. “There is a learning curve to become familiar with the code.”

ITTIA also sometimes has to overcome significant resistance by customers because db.* is an open source product. “They sometimes feel [an open source product] is something free that nobody is standing behind,” Montaseri says. The fact that ITTIA has been in business for five years, successfully implementing and supporting db.* with the largest of companies, helps give prospective customers some peace of mind.

One customer’s story

An example of one such customer is Oshkosh, a manufacturer of heavy trucks (not related to Oshkosh B’Gosh the maker of childrens clothes). Recently ITTIA announced that Oshkosh selected db.* for the newest iteration of its A3 Heavy Expanded Mobility Tactical Truck (HEMTT) military vehicle. NewsForge attempted to get Oshkosh to speak about db.*, but the company declined, so we had to rely on ITTIA’s account.

The A3 HEMTT is high-tech, compared to the average consumer’s car. Electronics in the truck control the various subsystems and produce fault codes when errors occur. The database built into the truck’s control module permanently stores the error codes and retrieves this information so that it may be displayed for the truck’s operators on small color displays. The A3 HEMTT is currently used by the U.S. Army in Iraq and Afghanistan.

The A3 HEMTT uses ARM Linux, an embedded Linux OS for the ARM processor, so the database Oshkosh would use had to run on that platform. Due to the life-and-death nature of operations in combat zones, the selected database had to be reliable, robust, and fast, and be simple to use and maintain. Also, because of the nature of embedded solutions, the database needed to have a small footprint. Oshkosh was also concerned about cost, reliable technical support, and the availability of professional training from an established company.

After spending months testing various solutions, including proprietary databases like Polyhedra, Montaseri says Oshkosh decided it needed something faster, cheaper, and more robust than an off-the-shelf SQL database could provide. In the end, the company chose db.* — and not just because of the zero license cost. “If I were to rank [Oshkosh’s requirements],” says Montaseri, “The first thing was technology, the second thing was no licensing fee, and the third thing was service.”

The power and complexity of db.* required Oshkosh engineers be given specific training. Oshkosh chose to do all of the training online. “We entertained them with an online training program, and provided consulting and technical support to make sure they were learning the product in a rapid fashion,” says Montaseri. “We made sure they received technical support rapidly. Engineers cannot wait when they have questions.”