DataNucleus AccessPlatform

The DataNucleus AccessPlatform provides persistence and retrieval of data to a range of datastores using a range of APIs, with a range of query languages. We provide a FactSheet for DataNucleus AccessPlatform in PDF and ODF formats.

DataNucleus AccessPlatform Checklist
  • Current version(s) : 3.3.6 (Galileo), 3.2.9 (Copernicus)
  • Old version(s) : 3.1.5 (Kepler), 3.0.10 (Newton), 2.2.3 (Geiger), 2.1.4 (Thomson), 2.0.5 (Bohr), 1.1.6 (Rutherford), 1.0.5 (Faraday)
  • License : Apache 2
  • APIs Supported : JDO, JPA, REST
  • Datastores Supported : RDBMS, Neo4j, LDAP, Excel (XLS/OOXML), XML, NeoDatis, JSON, ODF, HBase, Amazon S3, GoogleStorage, MongoDB, AppEngine/Datastore
  • Query Languages : JDOQL, JPQL, SQL, NeoDatis Criteria, NeoDatis Native
  • JRE required : 1.6+ (v3.1+), 1.5+ (v1.1-3.0), 1.3+ (v1.0)

Version Status and Documentation

Version Status APIs Released Support HTML (Online) Download
3.3 (Galileo) Developed JDO3.1, JPA2.1, REST Jun/2013 Free, Commercial HTML HTML | PDF
3.2 (Copernicus) Developed JDO3.1, JPA2.0, REST Mar/2013 Free, Commercial HTML HTML | PDF
3.1 (Kepler) Retired JDO3.1, JPA2.0, REST Jul/2012 Commercial HTML HTML
3.0 (Newton) Retired JDO3.0, JPA2.0, REST Aug/2011 Commercial HTML HTML
2.2 (Geiger) Retired JDO3.0, JPA2.0, REST Dec/2010 None HTML HTML | PDF
2.1 (Thomson) Retired JDO3.0, JPA2.0, REST Jun/2010 None HTML HTML | PDF
2.0 (Bohr) Retired JDO2.2, JPA1.0, REST Jan/2010 None N/A HTML | PDF
1.1 (Rutherford) Retired JDO2.2, JPA1.0, REST Feb/2009 None N/A HTML | PDF
1.0 (Faraday) Retired JDO2.2, JPA1.0, REST Sep/2008 None N/A HTML | PDF


Current development effort is focussed on continued development of current versions 3.2 and 3.3.

Do you want to help us develop this release or the next release of AccessPlatform? Does your company want to have some control over the direction we take? If so please go to our Forum and register your interest. Please also refer to this page for developing DataNucleus source code further.


In most applications, the performance of the persistence layer is very unlikely to be a bottleneck. More likely the design of the datastore itself, and in particular its indices are more likely to have the most impact, or alternatively network latency. That said, it is the DataNucleus projects' committed aim to provide the best performance possible, though we also want to provide functionality, so there is a compromise with respect to resource.

What is a benchmark? This is simply a series of persistence operations performing particular things e.g persist n objects, or retrieve n objects. If those operations are representative of your application then the benchmark is valid to you.

To find (or create) a benchmark appropriate to your project you need to determine the typical persistence operations that your application will perform. Are you interested in persisting 100 objects at once, or 1 million, for example? Then when you have a benchmark appropriate for that operation, compare the persistence solutions.

For performance of DataNucleus Access Platform, please refer to the Performance Tuning Guide and also refer to the following blog entry for our take on performance of DataNucleus AccessPlatform. And then the later blog entry about how to tune for bulk operations

GeeCon JPA provider comparison (Jun 2012)

There is an interesting presentation on JPA provider performance that was presented at GeeCon 2012 by Patrycja Wegrzynowicz. This presentation takes the time to look at what operations the persistence provider is performing, and does more than just "persist large number of flat objects into a single table", and so gives you something more interesting to analyse. DataNucleus comes out pretty well in many situations. You can also see the PDF here.

PolePosition (Dec 2008)

The PolePosition benchmark is a project on SourceForge to provide a benchmark of the write, read and delete of different data structures using the various persistence tools on the market. JPOX was run against this benchmark just before being renamed as DataNucleus and the results are found in the DataNucleus Wiki. The input data used for that benchmark run is found in JPOX SVN. Some comments on the PolePos benchmark :-

  • It is essential that tests for such as Hibernate and DataNucleus performance comparable things. Some of the original tests had the "delete" simply doing a "DELETE FROM TBL" for Hibernate yet doing an Extent followed by delete each object individually for a JDO implementation. This is an unfair comparison and in the source tree in JPOX SVN this is corrected. This fix was pointed out to the PolePos SourceForge project but is not, as yet, fixed
  • It is essential that schema is generated before the test, otherwise the test is no longer a benchmark of just a persistence operation. The source tree in JPOX SVN assumes the schema exists. This fix was pointed out to the PolePos SourceForge project but is not, as yet, fixed
  • Each persistence implementation should have its own tuning options, and be able to add things like discriminators since that is what would happen in a real application. The source tree in JPOX SVN does this for JPOX running. Similarly a JDO implementation would tune the fetch groups being used - this is not present in the SourceForge project but is in JPOX SVN.
  • DataNucleus performance is considered to be significantly improved over JPOX particularly due to batched inserts, and due to a rewritten query implementation that does enhanced fetching.