diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 4deba0f16e..2431e088f0 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -1,6 +1,7 @@ // suppress inspection "AsciiDocLinkResolve" for whole file .Introduction * xref:introduction:why-couchbase.adoc[Why Couchbase?] +* xref:introduction:getting-started-85.adoc[Getting Started with Couchbase Server 8.5] * xref:introduction:whats-new.adoc[What's New?] * xref:developer-preview:preview-mode.adoc[Developer Preview Mode] //* xref:introduction:editions.adoc[Couchbase Server Editions] diff --git a/modules/introduction/pages/getting-started-85.adoc b/modules/introduction/pages/getting-started-85.adoc new file mode 100644 index 0000000000..2d726d02a0 --- /dev/null +++ b/modules/introduction/pages/getting-started-85.adoc @@ -0,0 +1,48 @@ += Getting Started with Couchbase Server 8.5 +:description: Download, install, and take your first steps with Couchbase Server 8.5. + +[abstract] +{description} + +Couchbase Server 8.5 brings native encryption at rest for protecting data on disk without application changes, continuous backup with point-in-time restore for near-zero data loss, rank fusion for combining vector, full-text, and {sqlpp} results in a single hybrid search, and binary quantization for faster, more memory-efficient vector indexes, along with a range of other enhancements. + +To take advantage of all of these, launch a cluster with the Data, Index, Query, and Search services enabled, and use the xref:learn:buckets-memory-and-storage/storage-engines.adoc[Magma] storage engine for your buckets. Continuous backup and PITR need Magma buckets, and hybrid search with rank fusion and binary quantization needs the Query, Index, and Search services working together. + +[NOTE] +==== +Couchbase Server 8.5 is currently available as a private preview build. +The download link below is a placeholder and will be updated once the build is published. +==== + +== Download Couchbase Server 8.5 + +Download the private preview build from the link provided to you as part of the preview program: + +link:REPLACE_WITH_PRIVATE_PREVIEW_DOWNLOAD_LINK[Download Couchbase Server 8.5 (private preview)^] + +== Install Couchbase Server + +Install Couchbase Server 8.5 the same way as any other release. +Choose the guide for your platform: + +* xref:install:install-linux.adoc[Install on Linux] +* xref:install:install-package-windows.adoc[Install on Windows] +* xref:install:macos-install.adoc[Install on macOS] +* xref:install:getting-started-docker.adoc[Install with Docker] + +Once Couchbase Server is installed, set up your cluster: + +* xref:manage:manage-nodes/initialize-node.adoc[Initialize a Node] +* xref:manage:manage-nodes/create-cluster.adoc[Create a Cluster] +* xref:manage:manage-buckets/create-bucket.adoc[Create a Bucket] +* xref:manage:manage-security/manage-users-and-roles.adoc[Manage Users, Groups, and Roles] +* xref:install:testing.adoc[Verify the Installation] + +== See What's New + +Couchbase Server 8.5 introduces a number of new features and enhancements. +See xref:whats-new.adoc[What's New] for the full list, and for guidance on how to start using each one. + +== Check the Patch Notes + +For granular details on improvements, fixes, and known issues in each 8.5.x patch release, see the xref:release-notes:relnotes.adoc[Release Notes]. diff --git a/modules/introduction/pages/whats-new.adoc b/modules/introduction/pages/whats-new.adoc index 817883fe6a..377a45d95d 100644 --- a/modules/introduction/pages/whats-new.adoc +++ b/modules/introduction/pages/whats-new.adoc @@ -5,14 +5,14 @@ [abstract] {description} + -Couchbase Server 8.1 combines the strengths of relational databases with the flexibility, performance, and scale of Couchbase. +Couchbase Server 8.5 combines the strengths of relational databases with the flexibility, performance, and scale of Couchbase. +For information about platform support changes, deprecation notifications, and fixed and known issues, see xref:release-notes.adoc[Release Notes]. -For information about platform support changes, deprecation notifications, and fixed and known issues, see the xref:release-notes:relnotes.adoc[Release Notes]. [#new-features-81] -== New Features and Enhancements in 8.1.0 +== New Features and Enhancements in 8.5.0 This release introduces the following new features. -include::partial$new-features-81.adoc[] +include::partial$whats-new-85.adoc[] diff --git a/modules/introduction/partials/whats-new-85.adoc b/modules/introduction/partials/whats-new-85.adoc new file mode 100644 index 0000000000..5785532356 --- /dev/null +++ b/modules/introduction/partials/whats-new-85.adoc @@ -0,0 +1,389 @@ +[#section-new-feature-85] +=== Native Encryption at Rest + +[%collapsible] +==== +Elevate your data protection strategy with Couchbase Server 8.5, which features native encryption at rest to make sure your sensitive information is secured the moment it is written to disk, without requiring a single change to your application logic. +This enterprise-grade security effortlessly bridges the gap between stringent compliance requirements and operational efficiency by offering several key advantages: + +* *Effortless Compliance:* Easily meet PCI-DSS, HIPAA, and GDPR mandates for encryption at rest without modifying your existing application code. +* *Neutralized Breach Impact:* Ensure your data remains encrypted and unreadable, even if storage volumes, VM images, or backups are lost, stolen, or improperly decommissioned. +* *Total Key Control:* Leverage the simplicity of Couchbase-managed keys for an out-of-the-box setup, or bring your own (BYOK) via AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault, and other KMIP-compliant systems. +* *Proactive Security Hygiene:* Catch issues before they become incidents with configurable key rotation, on-demand re-encryption, and continuous key-health monitoring. + +To set up Native Encryption At Rest: + +. Set a master password to protect your local key store, which in turn secures KEKs, DEKs, and data on disk. +. Enable encryption via the Web Console or REST API, selecting the scope as bucket, system, or service-generated data. +. (Optional) Connect your own KMS if you want to manage keys yourself instead of using Couchbase-managed keys. +. Set your rotation policy (minimum 7 days) and trigger manual rotation or re-encryption as needed. +. Use Web Console alerts or the REST API from day one to monitor encryption status and key health. + +For more information, see xref:encryption-at-rest.adoc[Encryption at Rest]. +==== + +=== Continuous Backup and Point-in-Time Restore (PITR) + +[%collapsible] +==== +Continuous Backup and Point-in-Time Restore (PITR) is now included in Couchbase Server 8.5. +It continuously captures data mutations in the background as they happen, ensuring you no longer lose data in the gap between traditional scheduled backups. +This approach provides several key benefits: + +* *Shrinks your recovery point gap:* Continuous backup captures changes as they occur, effectively closing the window where mutations could otherwise be lost. + +* *Restores to the exact second:* Roll back to a precise point in time. This point can be right before an accidental deletion, corruption, or bad application write, for granular disaster recovery. + +* *Runs without a backup schedule to manage:* Once enabled, the process runs seamlessly in the background, eliminating the need to build or maintain a complex backup calendar. + +* *Retention you control:* Keep your continuous backup data for anywhere from 1 hour up to 60 days, giving you the flexibility to define how far back you need to restore. + +Before starting with PITR, ensure your cluster has 1 or more Magma buckets, as continuous backup is not available for Couchstore buckets. +Keep a regular traditional backup schedule (using `cbbackupmgr` or snapshots) running to provide the essential baseline that continuous backup restores build on. + +To enable PITR: + +. Enable Change History on the bucket as continuous backup requires it. +Once continuous backup is on, you can not disable Change History (bucket-wide or per collection). + +. Enable continuous backup on the bucket via the Web Console, the REST API, or the CLI. + +. Establish overlap with a periodic backup as PITR needs your continuous and periodic backups to overlap before it can run. +After enabling continuous backup, wait at least 1 backup interval, then trigger a full or incremental periodic backup using the Backup Service or `cbbackupmgr`. + +How restoring works: + +. When you need to restore, check the available restore window first. +This returns the earliest and latest timestamps you can restore to. + +. Stop continuous backup before restoring as a backup cannot run mid-restore. +This is required even when restoring into a different bucket. + +. Run the restore, specifying your target timestamp, the traditional backup archive, and the continuous backup location. + +. Re-enable continuous backup once the restore completes, so ongoing protection resumes. + + +For more information, see +==== + +=== Rank Fusion for Hybrid Searches + +[%collapsible] +==== +Couchbase Server 8.5 transforms your search experience by letting you combine vector, full-text, and N1QL/SQL++ query results into a single, unified ranked result set directly within your query. +By utilizing built-in rank fusion functions within the Query Service, you can achieve superior outcomes that simplify your architecture and enhance your results: + +* *Achieve better search relevance out of the box:* Hybrid search blends vector similarity with keyword matching or structured filters. +This method consistently outperforms any single method. +Rank fusion allows you to combine these approaches with a single function call, replacing complex, hand-rolled scoring logic. + +* *Streamline your application architecture:* Move away from client-side logic, multiple round trips, and custom scoring code. +With rank fusion, you execute the entire merging process as a single, efficient N1QL/SQL++ expression server-side. + +* *Tailor performance to your specific workload:* Pick the scoring approach that best fits your needs, whether it's a rank-based blend that avoids dependency on raw score scales or a weighted strategy for when you want a specific signal to dominate. + +Getting started with Rank Fusion is easy: + +. Write your individual queries such as the vector search, FTS query, and/or N1QL query you want to combine. Each should return results with an `id` and `score` field. + +. Combine with `reciprocal_fusion()` by passing an options object (scorer, normalization, weights), followed by your queries as subqueries or CTE/LET variables. + +. Tune and iterate to adjust weights, change the scorer, or add normalization to optimize relevance for your workload. + + +For more information, see . +==== + +=== Binary Quantization for Vector Indexes + +[%collapsible] +==== +Binary Quantization (BQ) is a powerful new quantization option for GSI and Search vector indexes in Couchbase Server 8.5, engineered specifically for the high-dimensional embeddings (768 dimensions and above) produced by modern AI models. +This feature enables you to optimize your vector infrastructure, delivering significantly faster performance and reduced storage overhead without the complexity of manual tuning: + +* *Accelerated index builds:* Rebuild or scale your vector indexes up to ~4x faster than with Product Quantization (PQ), minimizing your maintenance windows. + +* *Boosted query performance:* Achieve up to ~4x lower latency and 3x higher throughput on Hyperscale indexes, while maintaining high recall accuracy (Recall@10 ≥ 80%). + +* *Optimized storage footprint:* Benefit from on-disk storage that is comparable to, or slightly lower than, traditional PQ. + +* *Simpler configuration:* Eliminate the need for complex sub-quantizer tuning; BQ is designed to perform optimally out of the box, even on high-dimensional data. + +* *Broad index compatibility:* Seamlessly integrate BQ across Search vector indexes, Composite Vector Indexes, and Hyperscale Vector Indexes. + +To get started with Binary Quantization: + +. *Create a Search Vector Index with BQ:* Configure Binary Quantization directly within the Search index definition in the Couchbase Server Web Console or via the Search REST API. + +. *Create a Composite Vector Index with BQ:* Use the standard `CREATE INDEX` statement, specifying `"BQ"` as the quantization type in the description field of the `WITH` clause. + +. *Create a Hyperscale Vector Index with BQ:* Use a distinct `CREATE VECTOR INDEX` statement (rather than `CREATE INDEX`). + +. *Fine-tune with `nbit`:* Adjust the `nbit` parameter (valid values 1–9) if you need to trade off precision against index size. + +For more information, see [link to the BQ documentation page]. +==== + +=== Built-in SQL++ Reranking for Vector Search Results + +[%collapsible] +==== +Couchbase Server 8.5 introduces native reranking, enabling you to reorder vector search results using cross-encoder or LLM-based models directly within your queries. +By eliminating the need for external orchestration, this capability ensures you get the most relevant answers every time, offering several key advantages: + +* *More accurate results, not just more similar ones:* While vector search excels at recall, it does not always capture the true nuance of user intent. +Reranking bridges this gap by applying highly accurate relevance evaluation to your candidate set, ensuring your results are truly on target. + +* *Eliminate manual workarounds:* You no longer need to stitch together complex, custom pipelines with multiple functions and external calls to achieve high-precision reranking. + +* *A cleaner, declarative interface:* Simplify your code with a built-in function that replaces messy, hand-rolled patterns, making your search implementation easier to write, maintain, and optimize. + +Here's how to try reranking for Vector Search results: + +. Configure model access by setting up credentials for your reranking model provider (external API or hosted model) using the credential store. + +. Write a two-stage query to retrieve candidates with vector search, then apply `AI_RERANK` as a window aggregate to reorder results by relevance. +You can then tune your pipeline by adjusting the candidate set size and review the returned scores to balance latency against result quality. + +For more information, see +==== + +=== cbbackupmgr Support for WORM Object Storage + +[%collapsible] +==== +Make your Couchbase backups truly tamper-proof with new support for Write Once Read Many (WORM)-enabled object storage. +By integrating WORM policies directly into `cbbackupmgr`, your backup data is shielded from modification or deletion for the duration of your retention policy, with protection enforced at the storage layer rather than just by process, providing several distinct advantages: + +* *Satisfy regulatory mandates:* Easily meet strict immutability requirements from frameworks like SEC 17a-4, HIPAA, and GDPR, removing the need for external workarounds. + +* *Defend against ransomware:* Once written, backup data remains immutable; it cannot be encrypted or deleted during the retention period, even by an attacker with privileged access. + +* *Simplify your audits:* Demonstrate compliance effortlessly by pointing to storage-layer enforcement as definitive proof that your backup integrity remains uncompromised. + +* *Eliminate custom tooling:* Streamline your operations by removing the need for third-party scripts or complex manual processes. WORM compliance is now a native capability of `cbbackupmgr`. + +Get set up with WORM object storage: + +. Enable WORM on your object store by turning on Object Lock (or your provider's equivalent) on the target storage bucket. Set the retention period you need. + +. Point `cbbackupmgr` at the WORM-enabled bucket by configuring your backup repository with the appropriate cloud credentials and endpoint. + +. Back up as usual by running standard `cbbackupmgr backup` commands. You do not need to manage immutability separately; it is enforced by the storage layer. + +. Restore when needed by running `cbbackupmgr restore` against the WORM-protected repository following the normal restore procedure. + +For more information, see + +==== + +=== Credential Store + +[%collapsible] +==== +Couchbase Server 8.5 introduces a built-in credential store, creating a single, secure, and centralized hub for managing the credentials your services need to access external resources. +By moving API keys and tokens out of your query text, UDFs, and service configurations, you significantly improve your security posture and streamline operations through these key capabilities: + +* *Eliminate secret sprawl:* Establish a single source of truth for external credentials, ending the practice of scattering secrets across configurations, queries, and code. + +* *Neutralize leak risks:* Replace hardcoded secrets in UDFs or Eventing functions with secure ID references, ensuring sensitive tokens are never exposed in your source code and are significantly easier to manage. + +* *Simplify credential rotation:* Update credentials in one place and let them propagate automatically to every node and service, removing the need for tedious, per-service updates. + +* *Enforce granular access:* Use fine-grained RBAC to ensure that services and users can consume only the specific credentials they are explicitly authorized to use, moving away from all-or-nothing access. + +* *Secure and audit by default:* Leverage the cluster's native encryption-at-rest infrastructure to protect credentials, while maintaining a comprehensive, fully audited record of every creation, update, and access attempt. + +* *Automate enforcement:* Move beyond simple recommendations by setting mandatory expiration dates, ensuring credentials are rotated on schedule without relying on manual oversight. + +Build your credential store in minutes: + +. Enable node-to-node and configuration encryption on your cluster as the credential store requires it. + +. Create a credential by using the credential store REST API to add a credential with a type (bearer token, basic auth, certificate), an identifier, and an optional expiration. + +. Grant permission to the services that need it (Query, Eventing, Analytics, and so on) via the credential consumer role. + +. Reference it in your workloads by updating your queries, UDFs, Eventing functions, or Analytics links to point to the credential by ID instead of embedding the raw secret. + +For more information, see +==== + +=== Query Plan Stability + +[%collapsible] +==== +Couchbase Server 8.5 introduces Query Plan Stability, a powerful feature that lets you lock down and persist SQL++ query execution plans. +This ensures your critical queries consistently perform exactly as you tuned them, even when schema updates, index changes, or optimizer refinements occur. +By freezing these plans, you eliminate the risk of silent performance regressions after upgrades and gain the confidence that your production workloads will remain stable, regardless of changes in the underlying environment. + +This proactive control offers several key advantages for your mission-critical applications: + +* *Protect tuned performance:* A dropped index or schema update could otherwise push the optimizer toward a slower, unpredictable plan. Stability lets you decide how those scenarios are handled, rather than discovering them in production. + +* *Ensure consistency everywhere:* Because saved plans are automatically reloaded and primed on node startup, you maintain consistent behavior across restarts, rebalances, and disaster recovery scenarios. Plans are even preserved during cluster backup and restore. + +* *Define your own failure modes:* You control the outcome when a saved plan becomes invalid, choosing whether to have the query fail loudly or fall back to re-optimization, rather than relying on unpredictable defaults. + +To get started, enable plan stability by setting the plan stability mode to `on` via cluster settings. + +Then, execution plans for critical queries can be saved by using `PREPARE [name] SAVE AS ` to persist the optimized plan. +Configure your error policy by deciding whether an invalidated plan should raise an error or silently re-optimize. + +Monitor plan health via `system:prepareds` to check saved plans, their persistence status, and validity. +You should include `QUERY_METADATA` in your backups and make sure your backup strategy covers this bucket so that saved plans survive a restore. + +For more information, see +==== + +=== JWT Authentication + +[%collapsible] +==== +Couchbase Server 8.5 introduces support for *JSON Web Token (JWT) authentication* across the entire cluster, joining traditional username/password and mutual TLS (mTLS) authentication methods. By integrating directly with your external Identity Provider (IdP), Couchbase Server enables users, client applications, and automation tools to authenticate against *any REST or Key-Value (KV) endpoint* using token-based credentials. + +This evolution delivers several key benefits: + +* *Unified identity management:* Use the same IdP and token flow across both the Eventing Service and your broader infrastructure, eliminating the need to maintain a separate set of credentials. + +* *Enhanced security hygiene:* Protect your environment with short-lived tokens that expire automatically, significantly lowering the exposure risk associated with long-lived static passwords. + +* *Zero Trust alignment:* Ensure every API call is authenticated with a verifiable, scoped token rather than relying on shared static secrets. + +* *Automation-ready integration:* Empower your CI/CD pipelines and orchestration tools to obtain and use tokens programmatically, removing the manual overhead of storing or rotating static secrets. + +Here's how to get started with JWT Authentication: + +. *Configure your IdP:* Set up client applications, scopes, and users in your external Identity Provider (OIDC/OAuth 2.0) with claims that map to Couchbase Role-Based Access Control (RBAC) roles. + +. *Enable JWT validation on the cluster:* Configure the JSON Web Key Set (JWKS) URI, trusted issuer, and audience via `ns_server` / cluster security settings so Couchbase nodes can validate incoming tokens. + +. *Obtain an access token:* Request a signed JWT access token from your IdP using your standard OAuth 2.0 / OIDC authorization flow. + +. *Authenticate REST and KV requests:* Pass the access token in the `Authorization: Bearer ` header for REST API requests across cluster services (Admin, Query, Eventing, Analytics, Search) or configure SDK/client connections for token-based KV access. + +. *Review service-specific behaviors (e.g., Eventing & JIT provisioning):* If using Just-In-Time (JIT) user provisioning with dynamic group/role mapping, note that certain services—such as Eventing—block function creation and deletion under dynamic mappings. Set `jitProvisioning=false` or configure dedicated static role assignments if full lifecycle management (create, deploy, delete) is required via JWT. + +For more information, see + +==== + +=== File-Based Rebalance for the Data Service + +[%collapsible] +==== +Couchbase Server 8.5 introduces file-based rebalance for the Data Service, a powerful upgrade that transfers underlying vBucket data files directly rather than streaming individual mutations over DCP. + +This shift significantly accelerates rebalance times for large datasets and delivers several key advantages: + +* *Accelerated rebalances:* Bulk file transfer is far more efficient than replaying mutations one at a time, effectively shrinking the operational window during rebalances, especially on high-density buckets. + +* *Minimized workload disruption:* By reducing CPU and memory pressure on both source and target nodes, your cluster maintains consistent performance for running traffic even while rebalancing. + +* *Instant, effortless optimization:* This feature is enabled by default with automatic method selection, ensuring you benefit from faster rebalances immediately after upgrading with zero configuration required. + +* *Maximum impact where it counts:* Whether you are scaling out, replacing a failed node, or performing routine maintenance on clusters with large data volumes, this method drastically reduces the operational window for your most critical tasks. + +File-based rebalance is enabled by default and there's nothing to configure upon updating. +Rebalance as usual by adding, removing, or swapping nodes the way you always do. The cluster manager applies file-based transfer automatically where it's appropriate. + +You can tune a specific bucket if needed by setting `dataServiceRebalanceType` to `auto` (the default), `preferFileBased`, or `preferDcp` via the bucket REST API. + +For more information, see +==== + +=== XDCR Support for Cloud Native Gateway + +[%collapsible] +==== +Couchbase Server 8.5 introduces Cross Data Center Replication (XDCR) support for Cloud Native Gateway (CNG). +This means that you can specify CNG version 1.2.1 or later as an XDCR target, and CNG will front-end incoming connections to the Couchbase cluster, allowing the target cluster to expose only the CNG to the external environment, instead of needing to expose all of the nodes of the target cluster for direct access from external networks. + +* *Eliminate complex workarounds in Kubernetes / OpenShift environments:* Replace VPN tunnels, service meshes, and alternate address configurations with a single, managed ingress point. + +* *Align with network security:* Navigate Kubernetes network policies effortlessly, as routing through gateway endpoints avoids the challenges of direct pod-to-pod communication. + +* *Enforce Zero Trust and segmentation:* Keep traffic flowing through controlled, managed endpoints instead of direct paths between data service pods. + +* *Simple configuration of a private link service in public cloud environments:* Associate the private link service with a network load balancer that distributes load across CNG instances and solve how to setup your cluster as a private link service. + +* *Unify your routing model:* Re-use the same CNG pattern you already employ for client application traffic, reducing operational complexity. + +* *HLV Metadata Limitations for XDCR with Cloud Native Gateway:* In 8.5, XDCR with CNG cannot be used with any feature that requires HLV metadata (conflict logging, bi-directional XDCR with mobile buckets, forward local mutations only). This means that buckets with cross-cluster versioning enabled will not be able to use XDCR with CNG in 8.5. + +To start, deploy Cloud Native Gateway on the target cluster. Then: + +. Point your remote cluster reference at the CNG endpoint. Use the CNG hostname and port as the target address when configuring the XDCR remote cluster connection, instead of a direct pod address. + +. On the source cluster, create the XDCR remote cluster reference using the CNG endpoint for the hostname. + +. Prefix the CNG hostname with `couchbase2://`, and if the CNG gRPC port is not the default (`18098`), then you must also specify the port. ++ +NOTE: You must also provide the TLS certificate for the CNG SAN, not the root certificate for the target cluster. + +. The network type setting is not used with the CNG target. The username/password or client certificate/key remain the remote cluster access credentials. +. Create replications as usual by setting them up via the UI, CLI, or REST API the same way you always do. Traffic routes through the gateway automatically. +. Monitor as usual by using existing XDCR monitoring tools and statistics to confirm replication is flowing correctly over the CNG path. + +==== + +=== Improved Auto-Delete Behavior for Ephemeral Buckets + +[%collapsible] +==== +Couchbase Server 8.5 optimizes memory management for ephemeral buckets, ensuring you stop losing more cache data than memory pressure actually warrants. + +By introducing rate-limited and topology-aware auto-delete policies, rebalances and failovers no longer trigger outsized, unexpected purges of active data, allowing you to maintain consistent performance and predictability through these key improvements: + +* *Eliminate surprise over-deletion:* During rebalances, our updated logic prevents the system from misinterpreting replica vBuckets as reclaimable memory, effectively stopping the aggressive purging of your active data. + +* *Achieve predictable data retention:* Instead of sudden, disruptive bursts, deletions are now smoothly paced, helping you easily reason about how much data will survive a memory pressure event. + +* *Minimize topology-driven cache misses:* Because node additions, removals, and failovers no longer risk unexpectedly emptying active vBuckets, your downstream performance remains stable even as the cluster reshapes. + +* *Benefit instantly with zero configuration:* This smarter, more stable caching behavior is applied automatically to your existing ephemeral buckets the moment you upgrade. + +No action is required, since the improved behavior is automatic after upgrading and existing ephemeral buckets with auto-delete enabled benefit immediately. + +You can confirm your eviction policy by checking that the buckets you want this behavior on are set to NRU ejection (auto-delete). Buckets set to no ejection will keep rejecting writes when full instead of deleting data. + +Watch retention during your next rebalance, where you should see more stable data retention in ephemeral buckets through node additions, removals, and failovers. + +For more information, see + +==== + +=== Index scan/plan report + +[%collapsible] +==== +Couchbase Server 8.5 helps you stop guessing why an index scan is slow by surfacing a detailed index scan report directly inside your query execution plans. + +Rather than relying on a single, opaque total, you now gain granular visibility into timing breakdowns, partition behavior, and wait durations across both the index and query services, empowering you to: + +* *Identify actual bottlenecks:* Instead of guessing if slowness is due to disk I/O, network transfer, consistency waits, or scan processing, you can pinpoint the exact cause of any performance dip. + +* *Validate partition strategies:* Clearly see how many partitions were scanned versus skipped, ensuring your partition key strategy is delivering the intended performance gains. + +* *Provision with precision:* Right-size your indexer nodes using real-world metrics like CPU, disk IOPS, and memory usage rather than guesswork. + +* *Confirm pushdown efficiency:* Verify that group-by and aggregation pushdowns are executing effectively at the indexer level, preventing silent fallbacks to post-scan processing. + +* *Catch performance regressions early:* Use these new metrics as a baseline to immediately detect when a schema, index, or topology change degrades scan performance, rather than discovering it months later. + +How to see your report: + +. Use `EXPLAIN`, or set the query profile to `timings`, to see the detailed scan report in the execution plan output. + +. Look for warning signs such as high disk read durations, elevated wait times, or scatter/gather imbalances across partitions. + +. Act on what you find: +* If disk I/O dominates, consider faster storage or index replicas. +* If partition elimination isn't triggering, review your partition key strategy. +* If consistency waits are running high, evaluate whether `request_plus` is actually necessary for the workload. + +. Track it over time by using the scan report as a baseline. Re-check it after schema, index, or topology changes to catch regressions early. + +For more information, see +====