netdata · github-actions · Jul 3, 2026
diff --git a/docs/Exporting Metrics/Enable an exporting connector.mdx b/docs/Exporting Metrics/Enable an exporting connector.mdx
@@ -71,3 +71,29 @@ Replace `netdata` with an instance name of your choice, and change the `destinat
 Any further configuration is optional, based on your needs and the configuration of your Graphite database. See the [Graphite connector doc](/docs/exporting-metrics/connectors/graphite) and [exporting engine reference](/docs/exporting-metrics/exporting-reference#configuration-structure) for details.
 
 </details>
+
+<details>
+<summary><strong>Export to Multiple Databases Simultaneously</strong></summary>
+
+You can export metrics to more than one external database at the same time. To do this, add a separate connector section for each destination in the same `exporting.conf` file. Every section that has `enabled = yes` exports independently to its own destination, so by default all enabled destinations receive the same metrics from your Agent, unless you configure different settings per section, as described below.
+
+For example, to export to both a Graphite database and an OpenTSDB HTTP database, combine the two connector sections in a single `exporting.conf`:
+
+```text
+[exporting:global]
+    enabled = yes
+
+[graphite:my_graphite_instance]
+    enabled = yes
+    destination = localhost:2003
+
+[opentsdb:http:my_opentsdb_http_instance]
+    enabled = yes
+    destination = localhost:4242
+```
+
+Replace the instance names and `destination` values with those of your own databases. [Restart your Agent](/docs/netdata-agent/maintenance/service-control) to start exporting. As with a single connector, all enabled destinations begin receiving metrics **starting from the Agent restart time**, not the historical database.
+
+You can add as many connector sections as you need, even mixing different connector types in the same file. Each section can also define its own settings, such as its own `destination`, export interval, and metric filters. See the [exporting engine reference](/docs/exporting-metrics/exporting-reference#configuration-structure) for the full set of per-section options.
+
+</details>
diff --git a/docs/Netdata Agent/Configuration/Daemon.mdx b/docs/Netdata Agent/Configuration/Daemon.mdx
diff --git a/docs/Netdata Agent/Configuration/Database.mdx b/docs/Netdata Agent/Configuration/Database.mdx
@@ -20,9 +20,11 @@ Use [`edit-config`](/docs/netdata-agent/configuration#edit-configuration-files)
 ```text
 [db]
   # dbengine, ram, none
-  mode = dbengine
+  db = dbengine
 ```
 
+`mode` is also accepted for backwards compatibility.
+
 ## Tiers
 
 ### Retention Settings
@@ -33,7 +35,7 @@ In a Parent-Child setup, these settings control the Parent's total storage for m
 
 Child and Parent storage are independent:
 
-- A Child can keep local history based on its own `[db].mode`.
+- A Child can keep local history based on its own `[db].db`.
 - Streamed metrics can also be persisted on the Parent, in the Parent's own dbengine files.
 
 Retention size is enforced **per-tier**, not per Child, so all streaming Children share the Parent's tier quota. For Parent sizing guidance, see [Parent Retention Sizing](/docs/netdata-agent/resource-utilization/disk-&-retention#parent-retention-sizing).
@@ -58,7 +60,7 @@ You can change these limits using [`edit-config`](/docs/netdata-agent/configurat
 
 ```text
 [db]
-    mode = dbengine
+    db = dbengine
     storage tiers = 3
 
     # Tier 0, per second data. Set to 0 for no limit.

diff --git a/docs/Netdata Agent/Installation/Kubernetes Helm chart reference.mdx b/docs/Netdata Agent/Installation/Kubernetes Helm chart reference.mdx
@@ -12,7 +12,7 @@ slug: "/netdata-agent/installation/kubernetes-helm-chart-reference"
 
 <a href="https://artifacthub.io/packages/search?repo=netdata" target="_blank" rel="noopener noreferrer"><img loading="lazy" src="https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/netdata" alt="Artifact HUB" class="img_node_modules-@docusaurus-theme-classic-lib-theme-MDXComponents-Img-styles-module"></img></a>
 
-![Version: 3.7.168](https://img.shields.io/badge/Version-3.7.168-informational?style=flat-square)
+![Version: 3.7.169](https://img.shields.io/badge/Version-3.7.169-informational?style=flat-square)
 
 ![AppVersion: v2.10.3](https://img.shields.io/badge/AppVersion-v2.10.3-informational?style=flat-square)
 
@@ -468,6 +468,15 @@ true
 </td>
 			<td>The name of the service account to use. If not set and create is true, a name is generated using the fullname template</td>
 		</tr>
+		<tr>
+			<td>serviceAccount.annotations</td>
+			<td>object</td>
+			<td><pre lang="json">
+\{}
+</pre>
+</td>
+			<td>Annotations to add to the service account (e.g. an AWS IRSA `eks.amazonaws.com/role-arn`)</td>
+		</tr>
 		<tr>
 			<td>restarter.enabled</td>
 			<td>bool</td>

diff --git a/docs/Netdata Agent/Resource Utilization/Disk & Retention.mdx b/docs/Netdata Agent/Resource Utilization/Disk & Retention.mdx
@@ -21,6 +21,12 @@ Netdata offers two database modes to suit your needs for performance and data pe
 
 ## `dbengine`
 
+:::note
+
+By default, `dbengine` stores its metrics database files on disk. The exact location depends on your installation method, operating system, and whether you run Netdata in Docker or Kubernetes — see [Backing up a Netdata Agent](/docs/netdata-agent/maintenance/backup-and-restore-an-agent) for the default path and other Netdata data locations.
+
+:::
+
 Netdata's `dbengine` mode efficiently stores data on disk using compression. The actual disk space used depends on how well the data compresses.
 This mode uses a tiered storage approach: data is saved in multiple tiers on disk. Each tier retains data at a different resolution (detail level). Higher tiers store a down-sampled (less detailed) version of the data found in lower tiers.
 
@@ -69,12 +75,12 @@ For details about how dbengine enforces retention size limits, see [Retention Si
 
 Child and Parent storage are independent:
 
-- **On the Child (local):** Controlled by the Child's `[db].mode`.
+- **On the Child (local):** Controlled by the Child's `[db].db`.
 - **On the Parent (received stream):** Controlled by the Parent's settings. Metrics streamed from Children can be persisted on the Parent and count against the Parent's per-tier retention limits.
 
 **Configuring dbengine mode and retention**:
 
-- Enable dbengine mode: The dbengine mode is already the default, so no configuration change is necessary. For reference, the dbengine mode can be configured by setting `[db].mode` to `dbengine` in `netdata.conf`.
+- Enable dbengine mode: The dbengine mode is already the default, so no configuration change is necessary. For reference, the dbengine mode can be configured by setting `[db].db` to `dbengine` in `netdata.conf`.
 - Adjust retention (optional): see [Change how long Netdata stores metrics](/docs/netdata-agent/configuration/database#tiers).
 
 ## `ram`
@@ -87,5 +93,5 @@ The memory required per sample in these modes, is four bytes: `ram` mode uses `m
 
 **Configuring ram mode and retention**:
 
-- Enable ram mode: To use in-memory storage, set `[db].mode` to ram in your `netdata.conf` file. Remember, this mode won't retain historical data after restarts.
+- Enable ram mode: To use in-memory storage, set `[db].db` to ram in your `netdata.conf` file. Remember, this mode won't retain historical data after restarts.
 - Adjust retention (optional): While ram mode focuses on real-time data, you can optionally control the number of samples stored in memory. Set `[db].retention` in `netdata.conf` to the desired number in seconds. Note: If the value you choose isn't a multiple of 1024, Netdata will automatically round it up to the nearest multiple.
diff --git a/docs/Netdata Parents/Configuration Examples.mdx b/docs/Netdata Parents/Configuration Examples.mdx
@@ -45,7 +45,7 @@ Edit `netdata.conf` on the Child using the [edit-config](/docs/netdata-agent/con
 [db]
     # https://github.com/netdata/netdata/blob/master/src/database/README.md
     # none = no retention, ram = some retention in ram
-    mode = ram
+    db = ram
     # The retention in seconds.
     # This provides some tolerance to the time the child has to find a parent 
     # to transfer the data. For IoT, this can be lowered to 120.
@@ -81,7 +81,6 @@ Edit `stream.conf` on the Child using the [edit-config](/docs/netdata-agent/conf
 
 **Perfect for:** IoT devices, containers, or any resource-constrained system.
 
-
 ### Parent with Tiered Storage
 
 This example helps you configure a Parent with multiple [tiers of metrics storage](/docs/netdata-agent/database#tiers) to store different time ranges at different resolutions, for 10 Children with about 2k metrics each. Retention in each tier is restricted both in time and storage space, whichever is met first. See [retention settings](/docs/netdata-agent/configuration/database#retention-settings) for fine-tuning retention.
@@ -101,7 +100,7 @@ Edit `netdata.conf` on the Parent using the [edit-config](/docs/netdata-agent/co
 
 ```ini
 [db]
-    mode = dbengine
+    db = dbengine
     dbengine tier backfill = new
     storage tiers = 3
     dbengine page cache size = 1.4GiB
@@ -142,7 +141,6 @@ Edit `stream.conf` on the Parent using the [edit-config](/docs/netdata-agent/con
 
 **Perfect for:** Central monitoring servers with enough storage for historical data.
 
-
 ### Active-Active Parents
 
 This example guides you through setting up active-active Parents that sync with each other for high availability.
@@ -196,7 +194,6 @@ This example guides you through setting up active-active Parents that sync with
     api key = API_KEY
 ```
 
-
 ## Further Reading
 
 We strongly recommend the following configuration changes for production deployments:

diff --git a/docs/Netdata Parents/Parent Configuration Best Practices.mdx b/docs/Netdata Parents/Parent Configuration Best Practices.mdx
@@ -150,7 +150,7 @@ Adding 5–15% overhead for replication buffers, indexes, and metadata, plan for
 
 ```ini
 [db]
-    mode = dbengine
+    db = dbengine
     update every = 1
     storage tiers = 3
 
@@ -216,15 +216,15 @@ flowchart TB
 
 Netdata provides several benefits over other observability solutions:
 
-| Advantage                         | Description                                | Value                                                                 |
-|-----------------------------------|--------------------------------------------|-----------------------------------------------------------------------|
-| **Scalability & Flexibility**     | Multiple independent Parents               | Customized observability by region, service, or team                  |
-| **Resilience & Reliability**      | Built-in replication                       | Observability continues even if a Parent fails                        |
-| **Optimized Cost & Performance**  | Distributed workloads                      | Prevents bottlenecks and improves resource efficiency                 |
-| **Ease of Use**                   | Minimal setup and maintenance              | Reduces complexity and operational overhead                           |
-| **On-Prem Control**               | Data remains within your infrastructure    | Enhanced security and compliance, even when using Netdata Cloud. For a fully self-hosted control plane, see [Netdata Cloud On-Prem](/docs/netdata-cloud-on-prem)       |
-| **Comprehensive Observability**   | Segmented infrastructure with unified view | Deep visibility with tailored retention, alerts, and machine learning |
-| **Predictable Capacity Planning** | Published per-metric storage cost          | Allows accurate disk and hardware sizing for Parents                  |
+| Advantage                         | Description                                | Value                                                                                                                                                                                                                               |
+|-----------------------------------|--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| **Scalability & Flexibility**     | Multiple independent Parents               | Customized observability by region, service, or team                                                                                                                                                                                |
+| **Resilience & Reliability**      | Built-in replication                       | Observability continues even if a Parent fails                                                                                                                                                                                      |
+| **Optimized Cost & Performance**  | Distributed workloads                      | Prevents bottlenecks and improves resource efficiency                                                                                                                                                                               |
+| **Ease of Use**                   | Minimal setup and maintenance              | Reduces complexity and operational overhead                                                                                                                                                                                         |
+| **On-Prem Control**               | Data remains within your infrastructure    | Enhanced security and compliance, even when using Netdata Cloud. For a fully self-hosted control plane, see [Netdata Cloud On-Prem](/docs/netdata-cloud-on-prem) |
+| **Comprehensive Observability**   | Segmented infrastructure with unified view | Deep visibility with tailored retention, alerts, and machine learning                                                                                                                                                               |
+| **Predictable Capacity Planning** | Published per-metric storage cost          | Allows accurate disk and hardware sizing for Parents                                                                                                                                                                                |
 
 :::tip
 

diff --git a/docs/Netdata Parents/Streaming Routing Reference.mdx b/docs/Netdata Parents/Streaming Routing Reference.mdx
@@ -90,10 +90,10 @@ Once connected, the child maintains a persistent connection:
 Netdata automatically replicates missing historical data when reconnection occurs. Data is only lost if:
 
 - Child restarts during disconnection AND
-- Child uses `memory mode = ram` (metrics stored in memory) AND
+- Child uses `[db].db = ram` (metrics stored in memory) AND
 - Disconnection exceeds retention period (default: 1 hour for RAM mode)
 
-For persistent data, use `memory mode = dbengine`.
+For persistent data, use `[db].db = dbengine`.
 
 :::
 
@@ -201,8 +201,8 @@ The **Netdata Streaming** function (under the "Functions" tab) provides:
 - Comprehensive overview of all streaming connections
 - Status, replication completion time, and connection details
 - Works on both parent and child nodes:
-    - **On child**: Shows outgoing connections
-    - **On parent**: Shows incoming connections (InHops = 1 for direct children, >1 for proxied connections)
+  - **On child**: Shows outgoing connections
+  - **On parent**: Shows incoming connections (InHops = 1 for direct children, >1 for proxied connections)
 
 #### Viewing Logs