github.com/Jeffail/benthos/v3@v3.65.0/website/docs/components/outputs/azure_table_storage.md

---
title: azure_table_storage
type: output
status: beta
categories: ["Services","Azure"]
---

<!--
     THIS FILE IS AUTOGENERATED!

     To make changes please edit the contents of:
     lib/output/azure_table_storage.go
-->

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

:::caution BETA
This component is mostly stable but breaking changes could still be made outside of major version releases if a fundamental problem with the component is found.
:::

Stores message parts in an Azure Table Storage table.

Introduced in version 3.36.0.


<Tabs defaultValue="common" values={[
  { label: 'Common', value: 'common', },
  { label: 'Advanced', value: 'advanced', },
]}>

<TabItem value="common">

```yaml
# Common config fields, showing default values
output:
  label: ""
  azure_table_storage:
    storage_account: ""
    storage_access_key: ""
    storage_connection_string: ""
    table_name: ""
    partition_key: ""
    row_key: ""
    properties: {}
    max_in_flight: 1
    batching:
      count: 0
      byte_size: 0
      period: ""
      check: ""
```

</TabItem>
<TabItem value="advanced">

```yaml
# All config fields, showing default values
output:
  label: ""
  azure_table_storage:
    storage_account: ""
    storage_access_key: ""
    storage_connection_string: ""
    table_name: ""
    partition_key: ""
    row_key: ""
    properties: {}
    insert_type: INSERT
    max_in_flight: 1
    timeout: 5s
    batching:
      count: 0
      byte_size: 0
      period: ""
      check: ""
      processors: []
```

</TabItem>
</Tabs>

Only one authentication method is required, `storage_connection_string` or `storage_account` and `storage_access_key`. If both are set then the `storage_connection_string` is given priority.

In order to set the `table_name`,  `partition_key` and `row_key`
you can use function interpolations described [here](/docs/configuration/interpolation#bloblang-queries), which are
calculated per message of a batch.

If the `properties` are not set in the config, all the `json` fields
are marshaled and stored in the table, which will be created if it does not exist.

The `object` and `array` fields are marshaled as strings. e.g.:

The JSON message:
```json
{
  "foo": 55,
  "bar": {
    "baz": "a",
    "bez": "b"
  },
  "diz": ["a", "b"]
}
```

Will store in the table the following properties:
```yml
foo: '55'
bar: '{ "baz": "a", "bez": "b" }'
diz: '["a", "b"]'
```

It's also possible to use function interpolations to get or transform the properties values, e.g.:

```yml
properties:
  device: '${! json("device") }'
  timestamp: '${! json("timestamp") }'
```

## Performance

This output benefits from sending multiple messages in flight in parallel for
improved performance. You can tune the max number of in flight messages with the
field `max_in_flight`.

This output benefits from sending messages as a batch for improved performance.
Batches can be formed at both the input and output level. You can find out more
[in this doc](/docs/configuration/batching).

## Fields

### `storage_account`

The storage account to upload messages to. This field is ignored if `storage_connection_string` is set.


Type: `string`  
Default: `""`  

### `storage_access_key`

The storage account access key. This field is ignored if `storage_connection_string` is set.


Type: `string`  
Default: `""`  

### `storage_connection_string`

A storage account connection string. This field is required if `storage_account` and `storage_access_key` are not set.


Type: `string`  
Default: `""`  

### `table_name`

The table to store messages into.
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `string`  
Default: `""`  

```yaml
# Examples

table_name: ${!meta("kafka_topic")}
```

### `partition_key`

The partition key.
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `string`  
Default: `""`  

```yaml
# Examples

partition_key: ${!json("date")}
```

### `row_key`

The row key.
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `string`  
Default: `""`  

```yaml
# Examples

row_key: ${!json("device")}-${!uuid_v4()}
```

### `properties`

A map of properties to store into the table.
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `object`  
Default: `{}`  

### `insert_type`

Type of insert operation
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `string`  
Default: `"INSERT"`  
Options: `INSERT`, `INSERT_MERGE`, `INSERT_REPLACE`.

### `max_in_flight`

The maximum number of messages to have in flight at a given time. Increase this to improve throughput.


Type: `int`  
Default: `1`  

### `timeout`

The maximum period to wait on an upload before abandoning it and reattempting.


Type: `string`  
Default: `"5s"`  

### `batching`

Allows you to configure a [batching policy](/docs/configuration/batching).


Type: `object`  

```yaml
# Examples

batching:
  byte_size: 5000
  count: 0
  period: 1s

batching:
  count: 10
  period: 1s

batching:
  check: this.contains("END BATCH")
  count: 0
  period: 1m
```

### `batching.count`

A number of messages at which the batch should be flushed. If `0` disables count based batching.


Type: `int`  
Default: `0`  

### `batching.byte_size`

An amount of bytes at which the batch should be flushed. If `0` disables size based batching.


Type: `int`  
Default: `0`  

### `batching.period`

A period in which an incomplete batch should be flushed regardless of its size.


Type: `string`  
Default: `""`  

```yaml
# Examples

period: 1s

period: 1m

period: 500ms
```

### `batching.check`

A [Bloblang query](/docs/guides/bloblang/about/) that should return a boolean value indicating whether a message should end a batch.


Type: `string`  
Default: `""`  

```yaml
# Examples

check: this.type == "end_of_transaction"
```

### `batching.processors`

A list of [processors](/docs/components/processors/about) to apply to a batch as it is flushed. This allows you to aggregate and archive the batch however you see fit. Please note that all resulting messages are flushed as a single batch, therefore splitting the batch into smaller batches using these processors is a no-op.


Type: `array`  
Default: `[]`  

```yaml
# Examples

processors:
  - archive:
      format: lines

processors:
  - archive:
      format: json_array

processors:
  - merge_json: {}
```