Farrago Project FAQ

We already have MySQL, PostgreSQL, Derby, etc. Why does the world need another open-source DBMS?

Farrago is not an end-user product like these databases, which are focused on specific domains such as transaction processing, where they can already meet the needs of many users. Instead, Farrago provides a generic framework which can be specialized for a variety of DBMS domains such as federated query processing, data warehousing, multimedia, or replication. While it is possible to adapt a project like PostgreSQL for novel uses, significant customization requires permanently forking the codebase, because the architecture wasn't designed for extensibility beyond the type system. By contrast, Farrago has been designed for system-level extensibility via plugins, so the specialization process involves adding new components and behavior instead of replacing existing components with incompatible versions. The Farrago project model is very similar to Eclipse in this respect.

Why would I be interested in Farrago?

If you are a developer interested in creating a product with DBMS capabilities of some kind, using Farrago as a starting point can save you a lot of time. The Farrago architecture spans all of the layers required for a full DBMS, including: API's such as JDBC; SQL query parsing, validation, and optimization; query execution; storage and transaction managment; distributed data; and metadata management. And the implementation is fully component-based, with careful attention paid to dependencies, so that if you only want to reuse a self-contained subset such as storage management or SQL parsing, it's possible to do this without dragging in unrelated layers.

If you are an end user, you're more likely to be interested in a prepackaged distribution customized for a specific use such as data warehousing or metadata federation.

I would like to use Farrago to develop commercial software, but the GPL is a dead end for me. Do you offer dual licensing?

Farrago is being developed under the stewardship of The Eigenbase Project, a California non-profit. We strongly support open-source principles, and we believe that the GPL is the best vehicle for creating and protecting strong communities of software developers and users. So we encourage you to distribute your software under the GPL as well. However, if your organization prohibits development of or integration with GPL software, Eigenbase offers commercial licensing in exchange for significant contributions of code or other resources; contact us for more information.

Why does Farrago require Java?

Farrago's hybrid Java/C++ architecture opens up a number of opportunities not available to traditional DBMS implementations (or much more difficult):

Tight integration with Java-based application servers. For example, rather than reinventing cluster management, a clustered service based on Farrago could be managed through generic J2EE facilities such as JMX. There are similar opportunities for features such as distributed transactions, resource pooling, software update distribution, hot upgrades, etc.
Better extensibility environment. Writing a UDF in Java (with garbage collection) means the UDF can run in-process without having to worry about memory corruption and leaks affecting the server.
Seamless implementation for SQL standard Java stored procedures and object-oriented user-defined types.
JIT compilation of SQL expression and procedure code. Farrago is already able to implement many SQL scalar expressions and some relational expressions by generating Java code on the fly. (The same technique will be used for stored procedures.) This can be automatically compiled further into native code by JIT. This is a big win for commonly re-executed transactional statements as well as long-running complex queries.
Less security risk. Java is not perfect in this respect, but it reduces the chance of common exploits such as buffer overruns in non-performance-critical code. And the C++ portions use modern memory management techniques (string, vector, shared_ptr, etc), with STLport bounds-checking turned on for all debug builds.

Isn't Java slow? Doesn't that mean Farrago can't possibly compete with systems implemented entirely in C/C++?

Careful attention has been paid to keep Java out of the most important data processing paths. Where Java is used (metadata management, parsing, validation, and optimization, plus a limited role in executing generated code), its performance is acceptable.

What version of the SQL standard does Farrago implement?

We are developing towards SQL:2003.

What's with the name?

See the dictionary. But that's not the whole story.

Why a jackalope for the mascot?

The wily jackalope combines the speed of a jackrabbit with the fluid grace and complex headgear of an antelope, which seems appropriate for a hybrid Java/C++ system. In addition, the jackalope symbolizes a vision of elegance beyond our mundane reality (and is also reputed to be surprisingly savage when cornered).