New features in MarkLogic 12.1

This section describes the new features in MarkLogic 12.1.

AWS Graviton support

As of MarkLogic 12.1, Amazon EC2 instances powered by AWS Graviton processors are now supported for running MarkLogic 12. AWS Graviton processors are based on the ARM architecture (AArch64) and are optimized to provide the best price-performance on AWS. New MarkLogic Server AMIs running on AWS Graviton architecture are now available on the AWS Marketplace, and the MarkLogic CloudFormation template has been updated to allow selection of AWS Graviton as the architecture. See MarkLogic on Amazon Web Services for additional details.

EC2 instance types

MarkLogic Server on AWS Graviton provides support for AWS Graviton2, AWS Graviton3, and AWS Graviton4 EC2 instance types. Here is a breakdown of the newly supported EC2 instance types:

• t4g
• c6g, c6gd, c6gn, c7g, c7gd, c7gn, c8g, c8gd, c8gn, c8gb
• m6g, m6gd, m7g, m7gd, m8g, m8gd, m8gn, m8gb
• r6g, r6gd, r7g, r7gd, r8g, r8gd, r8gn, r8gb
• x8g, i8g, i8ge

Compatibility

EC2 instances using AWS Graviton processors are limited to the Amazon Linux 2023 and RHEL 9 (or compatible) operating systems.

The on‑disk and network formats used by MarkLogic Server are not compatible between x86_64 (Intel) and ARM (AWS Graviton) architectures:

• You cannot directly reuse or mount forests created on x86_64 nodes on AWS Graviton nodes—or vice versa.

• Mixing x86_64 and AWS Graviton nodes within the same cluster is not supported across architectures.

• Relying on physical copy methods (like copying forest directories) is not supported across architectures.

• Backups generated using one architecture cannot be loaded into a cluster with a different architecture.

Migrating to an AWS Graviton-powered EC2 cluster

Migrating an existing MarkLogic Server deployment to a new cluster running on AWS Graviton-based EC2 instances can vary significantly depending on your environment, operational practices, and data movement requirements.

Due to the cross-architectural incompatibilities between x86_64 and ARM, migration involves creating a new MarkLogic Server cluster on AWS Graviton, installing the supported MarkLogic Server release, and configuring the new environment with the previous system's settings.

After deploying the new cluster, you can typically continue using the data‑movement or deployment tools already in your environment—like MarkLogic Flux—to populate the new system and prepare it for production.

Since every deployment differs in topology, security configuration, application architecture, and operational processes, you must adapt the specific migration workflow and cutover strategy to your organization’s requirements.

Unsupported features

MarkLogic Server on AWS Graviton does not support the following features:

No ODBC driver

There are currently no plans to release an AWS Graviton build of the ODBC Driver RPM. However, the x86_64 build of the ODBC driver can interact with a MarkLogic Server on AWS Graviton cluster.

No support for ONNX Runtime

The Graviton build of MarkLogic Server 12.1 does not include ONNX Runtime functionality.

New Optic accessor function allows ad hoc querying and data exploration without reindexing

MarkLogic 12.1 introduces inline views for the Optic API through the new op.fromDocs() and op:from-docs() data access functions. Inline views enable ad hoc querying and data exploration without prior Template Driven Extraction (TDE) template configuration. Because the view structure is defined at query time, it can be adjusted on each execution to match the requirements of each query.

Like virtual views, introduced in MarkLogic 12.0, inline views do not require reindexing, and data extraction happens at query time. Documents are initially filtered with a CTS query, and column definitions are built dynamically using the op.columnBuilder or op:column-builder helper functions. The helper function supports specifying each column's scalar type, XPath expression or template dialect expression, nullability, collation, and other attributes. Inline views share the same limitations as virtual views.

See Building Inline Views in Get Started with Optic.

Parameterized Optic API CTS queries allow reusable query templates

MarkLogic 12.1 introduces support for parameterized CTS queries in the Optic API, allowing you to define reusable query templates with placeholders and bind values at execution time.

Parameterized CTS queries can be used with op.fromSearch(), op.fromSearchDocs(), and where(). Supported CTS constructor arguments and complete CTS queries can be parameterized, but not every CTS option accepts a parameter. Parameterized queries cannot be used to create Query By View views.

See Parameterizing an Optic Pipeline in Develop Server-Side Applications.

New Optic operator supports transitive closure

MarkLogic 12.1 introduces transitive closure through a new op.transitiveClosure() operator in the Optic API. Transitive closure finds all nodes reachable from a starting point through a specified relationship, enabling discovery of indirect connections such as genealogy trees, class hierarchies, and friends-of-friends.

The operator works with op.fromTriples() queries, accepts start and end node columns, and supports optional minimum and maximum path lengths. It is available in JavaScript, XQuery, the Optic DSL, Java, and Node.js.

See Transitive Closure in Develop Server-Side Applications.

Vector precision controls balance efficiency and numeric precision

MarkLogic 12.1 adds vec.precision() and vec.trunc() for creating reduced-precision vectors. Corresponding Optic, Java, and Node.js interfaces make these operations available across supported application APIs.

Template Driven Extraction also adds the vectorPrecision and vector-precision column properties. Values from 9 through 32 bits control the precision used to store approximate nearest neighbor (ANN)-index vector columns; omitting the property retains full precision. Changing the property requires reindexing, and a visible view can contain mixed precision while reindexing is in progress.

See Building Vector Queries in Get Started with Optic.

Excluded paths reduce universal index size and indexing work

MarkLogic 12.1 introduces excluded paths, which omit matching XML elements, attributes, JSON properties, and their descendants from word and value indexing in the universal index. Excluding content that does not need to be searched can reduce indexing work, index size, and resource use.

Excluded paths are configured per database and can be scoped with path expressions, collections, and directories. Adding, removing, or changing an excluded path triggers reindexing. Range indexes, fields, lexicons, triples, and TDE retain their independent configurations, although features that depend on universal-index terms can be affected.

New clusters preconfigure //vec:vector and //vector as excluded paths for the Documents database. Upgraded clusters retain their existing configuration.

See Excluded Paths in Administrate MarkLogic Server.

OAuth 2.0 single sign-on for MarkLogic Server interfaces added

MarkLogic 12.1 adds the OAuth 2.0 Authorization Code flow. The Admin Interface, Query Console, Monitoring Dashboard, and Monitoring History can authenticate users through an organization's identity provider and redirect them to the originally requested page.

The implementation supports PKCE, refresh tokens, dynamic redirects, and deployments that use load balancers and session affinity.

OpenSSL upgraded to the 3.5 release line

MarkLogic Server 12.1 uses the OpenSSL 3.5 release line, including the SQLClient and ODBC components.

Multi-step confirmation dialogs improve Admin Interface workflows

MarkLogic 12.1 replaces multi-page workflows with multi-step confirmation dialogs for these Admin Interface operations:

• Coupling clusters
• Decoupling clusters
• Database replication
• Database backup
• Database restore
• Forest backup
• Forest restore

The dialogs improve confirmation behavior, security, and user experience for these administrative operations.

Listed online configuration changes avoid unnecessary cache clearing

MarkLogic 12.1 does not clear caches or run index detection for these online configuration changes:

• Adding, removing, or changing scheduled tasks
• Changing reindexer throttle or timestamp settings
• Changing the rebalancer throttle setting
• Changing merge priority, blackout, timestamp, size, ratio, or vector-index-size settings
• Changing storage failure or journaling settings
• Changing replica-data or mapped-data preload settings