There’s been an unbro­ken wave of inter­est from all sides since the lat­est ver­sion of the Adobe Expe­ri­ence Man­ager (AEM) Con­tent Repos­i­tory was announced (AEM 6.0 has been avail­able for a few days now). So to address some of the main ques­tions — what are the most sig­nif­i­cant improve­ments to the platform?

One of the pri­mary goals was to address Web-scale, a scale-out archi­tec­ture, so that your cus­tomer expe­ri­ences (across all dig­i­tal devices) can be opti­mized and max­i­mized. New options for scal­a­bil­ity and per­for­mance are now avail­able and these can be imple­mented accord­ing to your busi­ness require­ments, allow­ing you to plan the long-term suc­cess of your dig­i­tal mar­ket­ing engagements.

But let’s start from the beginning…

 As in pre­vi­ous ver­sions of AEM, the con­tent repos­i­tory CRX (Con­tent Repos­i­tory eXtreme) includes (and builds on) the open-source imple­men­ta­tion of Apache jackrab­bit. Adobe engi­neer­ing teams are fully involved in the devel­op­ment of this open-source project, under the lead­er­ship of David Nuescheler (VP, Enter­prise Tech­nol­ogy at Adobe Sys­tems) and Dr. Michael Marth (Senior Engi­neer­ing Man­ager at Adobe Systems).

So, AEM 6.0 is still fully JCR-compliant (Java Con­tent Repos­i­tory). Since 2006, the JCR-specification has been the industry-leading stan­dard for content-centric applications.The advan­tages of this stan­dard in a het­ero­ge­neous land­scape are many and var­ied — often being the decid­ing fac­tor in real-life sce­nar­ios. The JCR API guar­an­tees long-term secu­rity when plan­ning at the appli­ca­tion level (layer); for exam­ple, code com­pat­i­bil­ity when upgrad­ing AEM.

The fol­low­ing 4 goals were pur­sued with the fur­ther devel­op­ment of the AEM con­tent repository:

  1. Scal­a­bil­ity: to cater for large repos­i­to­ries, with many dis­trib­uted, clus­tered nodes.
  2. Write-performance: to allow par­al­lel writes and high write-throughput.
  3. Content-scalability: to pro­vide sup­port for many child nodes and high ACL complexity.
  4. Search-performance: to real­ize focus-oriented con­tent indexing.

Results show that these goals have been achieved; dif­fer­ent JCR actions are all per­form­ing faster com­pared to the pre­vi­ous repos­i­tory ver­sion, mea­sured with Jackrab­bit 2.

These improve­ments have been made pos­si­ble by the intro­duc­tion of the Micro­Ker­nel imple­men­ta­tion. In the repos­i­tory archi­tec­ture this is respon­si­ble for the per­sis­tence of con­tent, tak­ing over (and sig­nif­i­cantly enhanc­ing) the pre­vi­ous con­cept of the TAR-PersistenceManager. The Micro­Ker­nel opti­mizes the per­for­mance via memory-mapped con­tent han­dling. Cur­rent vari­a­tions of the Micro­Ker­nel include TarMK and Mon­goMK, with oth­ers in the pipeline. While the TarMK man­ages the con­tent per­sis­tence of tar files (fast, local), the Mon­goMK for the Mon­goDB can be inte­grated. This con­cept enables sev­eral scal­ing options, all of which are depen­dent on your indi­vid­ual use-cases. Let’s look at a cou­ple of the possibilities:

  • CPU-Power for pro­cess­ing AEM con­tent: this can be increased as required through the addi­tion of extra AEM instances.
  • Read-Throughput: can be increased by the addi­tion of Mon­goDB Replicas.
  • Write-Throughput: repos­i­tory growth and dis­trib­uted author­ing can be increased by the use of extra Mon­goDB shards.

Accord­ing to engi­neer­ing mea­sure­ments and tests, the major goal of hor­i­zon­tal lin­ear scal­a­bil­ity across dif­fer­ent dis­ci­plines can be achieved by adding Mon­goDB shards.


AEM 6.0 has truly earned its title as an engine of inno­va­tion and offers sig­nif­i­cantly bet­ter per­for­mance. With the (optional) use of Mon­goDB, fur­ther, pow­er­ful scal­ing pos­si­bil­i­ties is pos­si­ble. These sim­plify your plan­ning and pro­tect your invest­ments for the future. So, AEM 6.0 is Webscale-ready…offering the best poten­tial for web expe­ri­ences that really make the dif­fer­ence for your customers.