What’s New in Version 8.0

If you do not specify a storage engine for a new Couchbase bucket, Couchbase Server Enterprise Edition 8.0 uses Magma with 128 vBuckets as the storage engine. This new storage engine option has a minimum memory quota requirement of 100MiB compared to the original 1024 vBucket Magma bucket’s requirement of 1GiB. See Storage Engines for more information about storage engines.

The new default storage backend for buckets is a behavior change that may cause issues if you rely on the previous behavior. Before upgrading, determine if your deployment scripts rely on the previous behavior. See Before You Upgrade for potential compatibility issues compared with the previous behavior.

Couchbase Server Enterprise Edition can now natively encrypt bucket, log, audit, and configuration data when writing it to disk.

This feature:

For more information about native encryption at rest, see Native Encryption at Rest.

You can configure the Data Service to stop writing to the data service path once the filesystem has filled to a configurable threshold. This limit can help avoid problems during recovery caused by a full filesystem. If the filesystem fills to the limit you set, Couchbase Server stops writing to the data storage path and returns an error instead. This limit is off by default. For more information, see Filesystem Free Space and Usage Limits.

You can enable a cluster-level option that allows durable writes to succeed even when they cannot meet their majority requirements. Use this setting to allow durable writes to succeed when nodes are unavailable due to failovers. For example, you can enable this option to prevent durable writes failing to a bucket with a single replica during an upgrade that uses the graceful failover followed by a delta recovery method.

See Auto-Failover and Ephemeral Buckets for more information about this feature.

The new Warmup behavior setting, configured using warmupBehavior in the REST API, controls when a persistent bucket becomes fully available for read and write operations after a bucket restart.

This setting replaces multiple warmup threshold parameters with a single configuration point:

For more information, see Initialization and Warmup.

The REST API now includes the per-bucket setting warmupBehavior. The previous advanced tuning settings warmup_min_items_threshold and warmup_min_memory_threshold have been removed from the cbepctl interface. The same changes in the warmup behavior settings are applicable to the Couchbase Cluster. For the REST API information, see warmupBehavior.

Now you can add or remove non-Data Services dynamically on existing nodes in a cluster, without adding or removing nodes. After you add or remove non-Data Services, the rebalancing operation is automatically triggered to distribute service workloads and complete the modification.

You can modify these services using the Couchbase UI, REST API, or CLI. The following services can be modified:

Backup Service now supports configurable retention periods for repositories and pruning of old backups from the UI and through the REST API.

For more information, see Retain Backups and Schedule Pruning.

Incremental backups now keep track of the backups they depend on. You cannot delete a backup if another incremental backup needs it, which is a default function. However, you can choose to override this protection from the UI and REST API. You can either schedule an automatic deletion of backups using the pruning function or delete manually.

For more information, see Delete Backups.

The following new settings for Data Services are added and made accessible through the Bucket REST API

/pools/default/buckets:

The settings warmup_min_items_threshold, warmup_min_memory_threshold, exp_pager_stime, mem_high_wat, and mem_low_wat are removed from cbepctl.

The new settings allow administrators to fine-tune bucket behavior and memory management directly through the REST API, eliminating the need to use cbepctl for these configurations.

For more information, see Creating and Editing Buckets and Memory.

XDCR detects and logs concurrent conflicts that occur in different clusters around the same time but on the same document version due to independent modifications by locally connected applications during Active-Active replication.

When conflict logging is enabled, XDCR records detailed information into a designated conflict log collection about each conflict event through 3 documents; the 2 conflicting documents and the conflict event message. These 3 documents are not replicated to other clusters. The conflict logs are for your information only.

For more information, see XDCR Conflict Logging Feature.

XDCR now supports the identification of incoming replications on a cluster, providing administrators with improved visibility and management of cross-cluster data flows. This enhancement allows you to view and distinguish replication streams that originate from remote clusters and are targeting the local cluster. The feature helps maintain replication transparency by showing which clusters are sending data in, how those streams are configured, and their current operational status, all from the UI or REST API.

For more information, see Incoming Replications and Listing Incoming Replications.

The xdcrDiffer diagnostic utility is a command-line tool that helps administrators compare document data between source and target clusters participating in XDCR. It identifies differences in document content, metadata, or presence across clusters to verify replication accuracy and consistency. This utility is included in the Server installation package for convenient access. In the earlier Couchbase Server versions, you’d build this utility from source using the xdcrDiffer GitHub repository.

For more information, see xdcrDiffer Utility.

XDCR supports the new Generic Services Log Level configuration using the REST API through the genericServicesLogLevel settings. Each key represents a service name, and its value specifies the log level. For more information, see XDCR Advanced Settings.

Couchbase Server now supports the Hybrid authentication mode in the certificate-based client authentication.

When Hybrid is selected:

This mode enhances flexibility for clients while enforcing strict security for node-to-node communication.

For more information, see Enable Client Certificate Handling.

Couchbase Server now supports simultaneous certificate-based client authentication and node-to-node encryption when the Mandatory option is selected. This configuration enforces the use of mutual TLS (mTLS) for all communications between clients and cluster nodes, ensuring that both entities are authenticated using X.509 certificates. In this mode, clients must present valid certificates to connect, and all internal cluster traffic is encrypted. This dual enforcement strengthens security by preventing unauthorized access, protecting data in transit, and maintaining end-to-end encryption across all communication paths.

For more information, see Enable Client Certificate Handling.

You can lock user accounts in Couchbase Server to prevent them from authenticating or maintaining prolonged active sessions. When an account is locked, all active UI sessions and long-running connections, such as Memcached or streaming connections, are immediately terminated. This feature is useful during maintenance operations or when you need to temporarily restrict user access without deleting the account. The account lock feature applies only to local domain user accounts and is available in the Enterprise Edition starting with Couchbase Server version 8.0 and later.

For more information, see Blocking User Authentication.

As an administrator, you can require a local domain user to change their password the next time they log in to Couchbase Server. This option is typically used when issuing a temporary or reset password to ensure that the user sets a new, private password upon their next authentication. When this setting is enabled, the user cannot access other features or perform operations until they successfully update their password.

For more information, see Force Password Change.

You can track user activity in Couchbase Server to view the last time a user made a request to the Cluster Manager. This capability, available through user auditing, helps administrators identify inactive or unused accounts that may need to be reviewed or removed. Administrators can monitor account activity patterns, and improve overall system visibility and security. This feature applies only to local domain users, as externally authenticated users, such as those managed through LDAP or external identity providers, cannot be tracked using this mechanism.

For more information, see Audit User Activity.

The SQL++ query language contains new statements and keywords to create, alter, and drop Hyperscale Vector indexes and Composite Vector indexes. You can specify the number of dimensions in the vector, the distance metric to use when comparing vectors, and the settings for quantization and index algorithms. For more information, see CREATE VECTOR INDEX and CREATE INDEX.

In addition, SQL++ now supports the following new statements to improve user, group, and bucket management:

For more information, see SQL++ Statements.

The SQL++ query language contains new functions to work with vector values.

These include:

For more information, see Vector Functions.

In addition to the new vector functions, the following SQL++ functions are new in Couchbase Server 8.0.

Automatic Workload Repository (AWR) is a new feature that automatically captures and maintains performance statistics for queries executed on a Couchbase cluster. It acts as a centralized repository for query performance data, enabling you to track query activity, analyze workload trends, and identify performance bottlenecks. It also enables you to generate reports to compare query performance over time and optimize your queries based on historical data.

For more information, see Automatic Workload Repository.

SQL++ now supports a new USING AI statement that leverages AI capabilities to generate SQL++ queries from natural language requests. For example, you can input prompts such as How many airlines are based in Europe or List the names of all hotels in the same city as an airport, and generate the corresponding SQL++ query.

For more information, see USING AI.

Couchbase Server Enterprise Edition now supports a new Auto Update Statistics feature that keeps the optimizer statistics up to date by automatically identifying and refreshing outdated statistics. This ensures that the Cost-Based Optimizer always has the latest statistics for generating efficient query plans.

For more information, see Auto Update Statistics.

Couchbase Server 8.0 now supports optimizer hints with the DELETE, UPDATE, and MERGE statements.

For more information, see Optimizer Hints.

In addition, you can now use negative keyspace hints, allowing you to instruct the optimizer not to use certain indexes or join methods. The supported hints are NO_INDEX, NO_INDEX_FTS, NO_USE_NL, and NO_USE_HASH.

For more information, see Negative Keyspace Hints.

8.0 introduces 2 new system keyspaces for group and bucket management:

For more information, see Get System Information.

You can now modify extended attributes (XATTRs) of documents directly through SQL++ statements such as INSERT, UPSERT, and UPDATE. You can include up to 15 XATTRs per query.

For more information, see INSERT, UPSERT, and UPDATE statements.

Couchbase Server 8.0 now includes an auto-reprepare feature for PREPARE statements. When enabled, a prepared statement automatically updates its query plan whenever GSI metadata version changes, ensuring it always uses newer, more efficient indexes as they become available.

For more information, see PREPARE.

You can now log query requests using 2 new qualifiers, statement and plan. This allows for logging based on the query text or specific values within the query plan.

For more information, see Completed Requests.

The INFER statement now supports the following options: array_sample_size, max_nesting_depth, and flags.

In addition, this statement also now automatically returns the meta.id() attribute, which provides the document keys in the output.

For more information, see INFER.

Use the partition_selection property in a Search request to choose how the Search Service chooses the specific partitions to search for a query.

For more information, see partition_selection.

Add a synonym collection and synonym documents to add synonym search support to a Search index. Use synonyms to return matches for words that share the same meaning as the term in your Search query, instead of exact matches.

For more information, see Add Synonyms to a Search Index or Add Synonyms with the Quick Editor.

Instead of the default type identifiers, you can now create custom document filters to control the documents added to your Search index from a type mapping.

For more information about how to configure type identifiers or create a custom document filter, see Set the Type Identifier for a Search Index.

Couchbase Server version 8.0 now supports the BM25 algorithm for scoring search results. The BM25 algorithm supports better hybrid searches and richer result rankings, as well as more stable result ordering across Search index partitions.

You can now choose to use tf-idf or bm25 from your Search index settings.

For more information about how bm25 scoring works, see Scoring for Search Queries.

This feature introduces a new handler OnDeploy in the Eventing function’s app code. The OnDeploy handler runs once when an Eventing function is deployed or resumed, before any mutations are processed. It supports the same JavaScript capabilities as the OnUpdate and OnDelete handlers. Use OnDeploy for one-time setup tasks such as registering a Timer or initializing resources required by the Eventing function.

For more information, see Eventing onDeploy handler.

Configurations can now be defined at the bucket, or scope level. Customers can set options like enable_curl or enable_debugger at the bucket or scope level.

For more information, see Eventing REST API.

Customers can configure the number of nodes on which an eventing function within a function scope executes, using the num_nodes_running setting. By default, all functions run on all nodes. If num_nodes_running is set, the system will attempt to run the function on the specified number of nodes. If fewer nodes are available, the function will run on all available nodes. This can be set at function scope config level.

For more information, see Eventing REST API.

Users can now set a timeout for each request in the curl function call. Specify the curl timeout value in seconds, which takes precedence over the script timeout.

For more information, see Eventing REST API.