LJ: Can you tell me a little about the history of db4o?

Christof: db4o is the native Java and .NET object database developed since 2000 by a small group of developers around Carl Rosenberger. Like many open-source projects, db4o was driven by users who felt there was an urgent need for an object persistence solution that was more efficient and better performing than incumbent solutions based on relational paradigms or flat file/serialization.

Christof Wittig

Jerry Fiddler

In 2004, after the product was successfully delivered to a handful of early customers, we felt it was ready for prime time. I was asked to join the company as CEO to grow the business. We named the company db4objects. The company is based in Silicon Valley.

db4objects brought db4o to the masses by adopting the open-source/dual-license model, as we know it from MySQL, and by raising funds from Silicon Valley luminaries, such as Mark Leslie, founding CEO of Veritas (and our chairman); Vinod Khosla, founding CEO of Sun Microsystems; and Jerry Fiddler, founding CEO of Wind River, who joined our board earlier this year. Jerry is here with me today to add his insight regarding db4objects.

LJ: What is db4o, and how are most of your customers using it?

Christof: db4o is an embeddable object persistence solution—and because this is such an awkward term, we call it an object database. However, databases often are associated only with Oracle, Versant, AS/400—large, single-unit, server-side solutions, and with a DBA. db4o is an embeddable component that helps to persist objects in distributed, multi-unit, client-side applications, where no DBA is present—that's why the term database is correct, though a bit ambiguous here.

Target applications span a broad range: devices (such as photocopiers and consumer electronics), mobile applications (such as doorstep delivery systems), packaged software (on a PC) and server-side middleware, and caches (such as in a SCADA system for railways or pipelines).

The unifying aspect is zero administration, reliability, high performance even with highly constrained resources, and it has to be a Java and .NET environment.

LJ: Would it be accurate to say that the market for db4o exists due to the popular adoption of a JVM in embedded systems?

Jerry: Yes. As Christof said, db4o goes where Java and .NET go. Rather than “embedded systems”, I much prefer to talk about “device software”.

Traditionally, most device software was written in C or C++, often with a strong focus on hardware rather than best software practices. But devices are becoming ever-more sophisticated, with more memory, faster CPUs and, maybe most important, rich connectivity. Both the software and the data they deal with are becoming much more complex. The software needs to ratchet up a notch, and Java and .Net provide two ways to do that. The RYO (roll-your-own) approach doesn't fly anymore—it's too cumbersome, too slow, not agile and doesn't connect well.

In many industries and application types, but especially in mobile, you now see more and more practices and technologies from servers and PCs being adopted on smaller devices, thanks to Moore's Law.

It's this convergence of technologies and practices, where Java embedded (and .NET with Windows mobile) is gaining ground rapidly. And, db4o is the only optimized persistence solution database for this space. This is one reason why I am so excited about this company.

LJ: What are the key differences in version 6?

Christof: Performance, performance, performance.

LJ: That's it?

Christof: That's most of it, yes. Any product in this space should focus on performance, because it's the number-one concern of developers. A product that doesn't address performance in this space either is not user-driven or simply doesn't have any.

For the new db4o version 6, it's not only about being a little faster. Version 6 has up to ten times faster response times, in some cases even 250 times. So it's not about being a little faster, it is about enabling a whole new set of functions (such as complex, ORed queries) and applications (for example, for small devices, where we have decreased the demand on memory consumption up to 90% and are making it more deterministic).

LJ: How did all these highly significant changes come about?

Christof: There's a technical and there's an organizational answer to this.

The technical answer is the use of a new B-Tree index architecture, first introduced in v5.5 a few months ago, which we could leverage to achieve these amazing results.

The organizational answer is what links all of this to open source. Our user community has driven the product road map for this release. Their clear number-one priority is performance, but there also are many other, less spectacular but relevant improvements, such as faster defragmentation, a new server-side cursor technology and an improved, less Java-esque .NET API.

LJ: So how did you orchestrate version 6 in a user-driven fashion?

Christof: We started off in early 2006 with a user survey where we gathered more than 1,000 responses and votes. We then gathered with some users at the first db4o User Conference in July 2006 in London, where we spec'd out some of the details. And while we were producing, we were getting feedback, sometimes in two-hour intervals—because that's the release cycle of our continuous builds! Even our weekly planning meetings are now Skype-casted, so the core developer team always remains in touch with the community of users out there.

LJ: How much of the changes in version 6 were the result of commercial developer input vs. the Open Source community.

Christof: We don't make this distinction. Even the contracted and paid developers are as much a part of the community as any community member is part of our company. There is not an “us” and “them”; there is only a “we”. It's a collaborative approach. You earn your say by merit (ideas and contributions), not by rank, seniority, title or politics.

Jerry: That's the really exciting part of db4o. At Wind River, we were always working hard to find ways to connect and engage the developer community, but it was always a challenge. The Open Source world, and especially db4o, has really honed the connection of the user community into the company in a seamless and low-friction manner.

The way db4o has built and nurtured its community of now 15,000 registered developers is amazing. I think it's the only way to build a company in this space today, and db4objects has done a fantastic job to walk their talk. Open-source and community collaboration is not only a label, it's also a true commitment. The user community is an integral part of product development and support.

At our board meetings, we feel this invisible stakeholder (the user community) sitting right there—and she has a big say in what we do and how we allocate resources.

LJ: We've been hearing database developers cry for a good database without the overhead of SQL for a long time. I know comparing something like MySQL or PostgreSQL to a JVM-based database is largely apples to oranges, so I'm sorry if this question seems unfair. But, why do you think you're among the first, if not the first, to listen to this demand?

Christof: It's the focus on the developer rather than on the DBA. We don't go well with DBAs—and its enterprise IT organization. We go well with applications where the developer “owns” the data in terms of anticipating its administration needs in the application rather than relying on runtime database administration. Just think of the software in your car. You expect your vendor to take care of the database administration, don't you? Or, do you want to hire a DBA to defrag your central car CPU?

There are many applications out there that the (relational) database vendors don't see (because they talk to CIOs and DBAs day in and day out). So, although they all have “light”, “compact” or “embedded” products, they are usually just teaser products to lure you into their full-blown server version. But these products aren't optimized for embedded, nor are their sales organizations. As a result, none of the big vendors holds more than 5-10% market share, while 50% of the developers, according to Chris Lanfear's research at VDC, still write their own persistence solutions today!

Jerry: Combine this with the power of open source, a totally new paradigm, which is essentially a low-cost production and distribution model for software, and then you can see that a small, focused player like db4objects (just like Sleepycat, JBoss or MySQL) can have a real impact in the market place, despite its initially more limited resources.

Because db4o is so profoundly connected to the user community, developers know that the users like and want the software. Because of the dual-license model, developers can work with the software immediately, without going through management and purchasing, at least for the prototyping stage. Then, developers can go to management with a working, demonstrable project. Now, there's really no decision left for the CIO to make—it's a done deal. It turns the entire decision-making process upside down. From a db4o perspective, it enables very low sales and marketing costs, which in turn feeds back and enables this very democratic process of acquiring users and customers. Compared to a traditional software sales and marketing structure, it's really lovely.

So the timing is right—from the market, the open-source perspective and the technology perspective.

LJ: Do you have an SQL compatibility layer for those who want to use db4o but want to use it in the same way they might use another SQL database?

Christof: Sure. But it's not a layer, it's a replication service called dRS (db40 Replication System).

Why would you want to access your data on your smartphone with SQL? You access it only with your application.

But what is even better is to sync this data with back-office systems, which typically store data in the tables of Oracle or MySQL. Then, you access it with your report writer or data-mining tool right there where you really need it. The dRS, powered by Hibernate, provides this bilateral synchronization with all major RDBMSes, making db4o entirely compatible with legacy systems.

This is an excellent example, by the way, of how the community drove our product decisions. We contemplated internally, like all closed-source object database vendors before us, to provide an SQL access layer, because people wanted to check this item off their list in database evaluations. Sales teams often pressure you to make decisions that are not necessarily the best—“we must have SQL or we don't win this deal.”

When we proposed the idea, our users begged us not to do it. They did not want us to contort db4o for the sake of some managers who simply don't get it. They said, “Make it data-compatible with the dRS, but don't bring the entire overhead of SQL back through the back door. We don't want it!”

Can you imagine? It was a rebellion of the developers against their managers, who forced them to use tools that simply didn't give them the ability to do their jobs. Previously, 50% of our target developers ended up writing their own database! SQL wasn't good, but anything other than SQL wouldn't pass their managers' desks for approval.

And then along came open source. Open source empowered developers to make autonomous decisions. They can now go to their managers with a proof of concept and show: “See, we can ship 10% faster than our competition, and this is due to the fact that I disrespected the SQL-only policy in our organization.” This is where real innovation comes from!

LJ: There seem to be similarities in your business model to things like Qt and MySQL, both of which are also dual-licensed commercial and open-source projects. I get the sense, however, that there are key differences too. Can you elaborate on those differences?

Christof: I am very familiar with MySQL since I am a Stanford researcher and have worked extensively with it.

MySQL has a relational database, and, by definition, is not particularly suited for embedded use. Most relational databases, based on SQL—a DBA language—are built for and sold to end users (DBAs and their CIOs). RDBMSes are not doing too well as OEM products, and, in fact, the MySQL Network subscription, an end-user offering, currently is overtaking MySQL's traditional embedded business in revenue.

Our product, based on native Java or .NET—the developer's language—is sold to product developing companies as an OEM component. Being open source, it's attractive for evaluation and optimization. For redistribution in non-GPL'd products, people then choose the commercial license without the GPL constraints, but with indemnification and specific support packages.

LJ: Can you give me a Java code example of how someone might open a database table, query the table and fetch some fields?

Christof: Wow. I'm just the CEO...Jerry can you help?

OK, here's something with respect to queries, showing how we cater our product to Java or .NET developers, not DBAs.

Here's a query in plain Java with what we call “Native Queries” for all students under 20 and with grade A:

List<Student> students = database.query<Student>(new Predicate(){
   public boolean match(Student student){
         return student.getAge() < 20
               && student.getGrade().equals(gradeA);}})

And here's the equivalent in JDOQL, to take one example for SQL:

String param = "String gradeParam"
String filter = "age < 20 & grade == gradeParam";
Query q = persistenceManager.createQuery(Student.class, filter);
q.declareParameters(param);
Collection students = (Collection)q.execute(gradeA);

What do you see? Pure Java in the first, strings in the second. The strings are aliens. They are like a little bit of a Chinese poem in an English poem—they simply don't fit.

What's the benefit of being native to Java? I'll give you two reasons, though there are many more:

Now, not refactoring means increased bugs, more maintenance costs, less reuse of software, as we all know. So it comes down to developer productivity once again.

With db4o, you build better and leaner code faster. You can go home at five.

Don't get me wrong: it's not a solution for everything, for example, to build an application that connects to a legacy database. But if it is appropriate, such as in a mobile app, where there's no legacy, you shouldn't really break your fingers and induce all the SQL complexity that is of no use at all, as there's no DBA around.

Of course, you still can use SQL for compliance purposes, but then you may find that your competitor has it faster, more agile and leaner, less buggy, more performance and more feature-rich—with db4o. That's not where you want to be as a developer or as a company.

LJ: Can you mention some examples of companies that have adopted db4o? How are they using the product, and how has that productivity played out?

Christof: Boeing builds the P-8A Multi-Mission Maritime Aircraft for the US Navy with db4o. Boeing says, “db4o provides the advantages of significantly lower database administration and improved developer productivity. db4o helps Boeing to manage development costs and schedules while also reducing operational costs.”

Ricoh in Tokyo with $17 billion in sales just decided to build its future photocopier models with db4o. Testuo Ito, the software lead, says, “db4o provides a persistence solution for our broad range of technical challenges and for our stringent quality standards. After a long period of evaluation, we found that db4o has the flexibility to fit our cutting-edge architectures, which aim to achieve better productivity in our object-oriented software development.”

BOSCH Sigpack, worldwide leader in fully automated packaging technology with $800 million in sales, relies on db4o to deliver its Delta XR-31 robot: “Our biggest concern is shortening our commissioning time. The use of db4o on the data back end has helped us to achieve a time-saving effect of at least 10% on each project.”

Intel says, “db4o will make application development much easier for our group. The OR mapper/SQL database alternative really did not allow us to do everything we needed and forced us to contort our application designs. By comparison, implementing with db4o was seamless and worked within our existing architecture.”

Want more?

LJ: Thanks, that is impressive. But how does that scale? What kind of adoption rate has db4o seen over the past few years?

Christof: We now have 15,000 registered developers and potentially 2-3x unregistered developers—in some two years, nearing 1,000,000 downloads. So far, we have closed 200 commercial design win deals. We're growing more than 100% each year.

LJ: That's quite a rapid rate of increase in adoption. Given that the new version has such a dramatic performance increase, how do you expect that to play in your future growth? I would expect performance to be a huge factor in embedded systems, so I would expect a big increase. But is there any other factor I'm missing that could add to or subtract from a big spike in adoption?

Christof: Performance is crucial, but there's a wide spectrum.

We will, for instance, provide better performance to our client/server users. Not that you run db4o as a client/server application on a mobile phone, but there are many more instances where multiple (embedded) clients connect to a (embedded) database server. It's wild what's going on out there. That should make us, again, attractive for a larger and larger crowd.

LJ: Because much of your market consists of embedded systems, I would assume most of your registered users are using db4o in devices they sell. That means they have to use the commercial version, right? If my assumption is wrong, why?

Christof: No.

We define embedded—like Carl Olofson from IDC—different from devices. Embedded to us means “invisible to the end user”. And that's a much larger market than device software, though with similar characteristics. Packaged software is a good example for embedded, yet not device software. And strictly speaking, the mobile applications that our ISV customers sell on Handango for the smartphone are not “device software”, but still embedded. All these are our core market.

In our community we also have end users, that use (sometimes “abuse” it for prototyping)—small systems, nonprofits, academia. That's great, so we get more people to love db4o, but sometimes they go beyond the scope of what db4o is designed for.

The commercial part kicks in when someone wants to redistribute db4o and does not want to go GPL with its own intellectual property. These guys then come to us and look for an alternate, safer licensing option, which we provide with our flexible OEM commercial terms. They also look for indemnification and a direct support option, when someone responds in 24 hours or less, guaranteed.

Of course, we also have embedding users under the GPL, such as ITAnyplace, an open-source mobile platform that extends applications and content to mobile devices.

Any user counts and is welcome, as she strengthens our ecosystem and is lost revenue to our closed-source competitors.

LJ: What other products or add-ons do you have available for db4o?

Christof: I mentioned the db4o Replication System (dRS), to provide compatibility with back-end RDBMSes, such as Oracle and MySQL.

The other add-on is the ObjectManager, a UI that comes in a total rewrite dubbed v6.0, including many user demands for the handling of large data sets and lots of enhancements around database inspection and application debugging.

These tools are open source too, and available under dual licenses.

LJ: Thanks again for taking the time to talk with us!

Christof and Jerry: Thanks for your interest and your time!