You are here: Tuning > Native Query Optimization

Native Query Optimization

Native Queries will run out of the box in any environment. If optimization is turned on (default) Native Queries will be converted to SODA where this is possible, allowing db4o to use indexes and optimized internal comparison algorithms.Otherwise Native Query may be executed by instantiating all objects, using SODA Evaluations. Naturally performance will not be as good in this case.

Optimization Theory

For Native Query Java bytecode and .NET IL code are analyzed to create an AST-like expression tree. Then the flow graph of the expression tree is analyzed and converted to a SODA query graph.

For example:


List<Pilot> pilots = container.query(new Predicate<Pilot>() {

public boolean match(Pilot pilot) {

return pilot.getName().equals("Michael Schumacher")

&& pilot.getPoints() == 100;



First of all the following code will be extracted:


Then a more complex analysis will be run to convert the contents of the #match method into a SODA-understandable syntax. On a simple example it is easy to see what will happen:


return pilot.getName().equals("Michael Schumacher") && pilot.getPoints() == 100;

easily converts into: == "Michael Schumacher"

CANDIDATE.points == 100

NQ Optimization For Java

NQ optimisation on Java requires db4onqopt.jar and bloat.jar to be present in the CLASSPATH.The Native Query optimizer is still under development to eventually "understand" all Java constructs. Current optimization supports the following constructs well:

This list will constantly grow with the latest versions of db4o.

Note that the current implementation doesn't support polymorphism and multiline methods yet.

db4o for Java supplies three different possibilities to run optimized native queries, optimization at

  1. query execution time
  2. deployment time
  3. class loading time

For more information on NQ optimization see Monitoring Optimization.