---
title: MULTIPLE_EXPRESSIONS_FOR_ALIAS ClickHouse® error
seo_title: "MULTIPLE_EXPRESSIONS_FOR_ALIAS Error Guide"
meta:
  description: Learn how to fix the MULTIPLE_EXPRESSIONS_FOR_ALIAS error in ClickHouse and Tinybird. Understand what causes it and see examples of how to resolve it
---

# MULTIPLE_EXPRESSIONS_FOR_ALIAS ClickHouse® error

{% callout %}
This error usually means you have multiple expressions with the same alias name in your SELECT clause. Each alias must be unique within a query.
{% /callout %}

The `MULTIPLE_EXPRESSIONS_FOR_ALIAS` error in ClickHouse® (and Tinybird) happens when you try to use the same alias name for multiple expressions in a SELECT clause. Each column alias must be unique within a query to avoid ambiguity.

## What causes this error

You typically see it when:

* Using the same alias for multiple columns in SELECT
* Having duplicate alias names in subqueries
* Using the same alias in UNION queries
* Having conflicting aliases in JOIN queries
* Using reserved words as aliases
* Collisions between columns and functions (for example, `col AS value` and `count(*) AS value`)

## Example errors

```sql {% title="Fails: duplicate alias names" %}
SELECT user_id as id, event_id as id FROM events
```

```sql {% title="Fails: same alias in UNION" %}
SELECT user_id as id FROM events
UNION ALL
SELECT user_id as id FROM events
```

```sql {% title="Fails: conflicting aliases in JOIN" %}
SELECT u.id as id, e.event_type as id FROM users u JOIN events e ON u.id = e.user_id
```

```sql {% title="Fails: subquery with duplicate aliases" %}
SELECT * FROM (
    SELECT user_id as id, event_id as id FROM events
) t
```

## How to fix it

### Use unique alias names

Give each column a unique alias:

```sql {% title="Fix: unique aliases" %}
SELECT user_id as user_id, event_id as event_id FROM events
```

### Use descriptive aliases

Make aliases more descriptive to avoid conflicts:

```sql {% title="Fix: descriptive aliases" %}
SELECT user_id as user_identifier, event_id as event_identifier FROM events
```

### Use table prefixes

Prefix aliases with table names:

```sql {% title="Fix: table prefixes" %}
SELECT u.id as user_id, e.id as event_id
FROM users u JOIN events e ON u.id = e.user_id
```

### Remove unnecessary aliases

If aliases aren't needed, remove them:

```sql {% title="Fix: remove unnecessary aliases" %}
SELECT user_id, event_id FROM events
```

## Common patterns and solutions

### Simple column selection

When selecting columns with aliases:

```sql {% title="Correct: unique aliases" %}
SELECT
    user_id as user_identifier,
    event_type as event_category,
    timestamp as event_time
FROM events
```

### Aggregated columns

When using aggregate functions:

```sql {% title="Correct: unique aggregate aliases" %}
SELECT
    user_id,
    COUNT(*) as event_count,
    SUM(value) as total_value,
    AVG(value) as average_value
FROM events
GROUP BY user_id
```

### JOIN queries

When joining tables with similar column names:

```sql {% title="Correct: table-specific aliases" %}
SELECT
    u.id as user_id,
    u.name as user_name,
    e.id as event_id,
    e.event_type as event_category
FROM users u
JOIN events e ON u.id = e.user_id
```

### UNION queries

When combining results from multiple queries:

```sql {% title="Correct: unique aliases in UNION" %}
SELECT user_id as user_identifier, 'user' as source FROM users
UNION ALL
SELECT event_id as user_identifier, 'event' as source FROM events
```

{% callout type="caution" %}
In UNION ALL, column names are taken from the first SELECT. Subsequent SELECTs should use implicit column order, not repeated aliases.
{% /callout %}

## Advanced solutions

### Using CTEs with aliases

When using Common Table Expressions:

```sql {% title="CTEs with unique aliases" %}
WITH user_stats AS (
    SELECT
        user_id as user_identifier,
        COUNT(*) as event_count
    FROM events
    GROUP BY user_id
),
event_stats AS (
    SELECT
        event_type as event_category,
        COUNT(*) as type_count
    FROM events
    GROUP BY event_type
)
SELECT
    us.user_identifier,
    us.event_count,
    es.event_category,
    es.type_count
FROM user_stats us
CROSS JOIN event_stats es
```

### Subqueries with aliases

When using subqueries:

```sql {% title="Subqueries with unique aliases" %}
SELECT
    u.id as user_id,
    u.name as user_name,
    (SELECT COUNT(*) FROM events e WHERE e.user_id = u.id) as user_event_count
FROM users u
```

### Window functions with aliases

When using window functions:

```sql {% title="Window functions with unique aliases" %}
SELECT
    user_id,
    event_type,
    timestamp,
    ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY timestamp) as user_event_rank,
    ROW_NUMBER() OVER (ORDER BY timestamp) as global_event_rank
FROM events
```

## Best practices

### Naming conventions

* Use descriptive, unique alias names
* Avoid generic names like `id`, `name`, `value`
* Use table prefixes when joining multiple tables
* Be consistent with naming patterns

### Query structure

* Plan your aliases before writing complex queries
* Use meaningful names that describe the data
* Avoid reserved words as aliases
* Test queries with simple aliases first

### Documentation

* Document your alias naming conventions
* Use consistent patterns across your codebase
* Comment complex queries with alias explanations
* Maintain a glossary of common aliases

## Tinybird-specific notes

In Tinybird, this error often occurs when:

* Building Pipes with conflicting column names
* Using Materialized Views with duplicate aliases
* Working with nested Pipes that have similar schemas
* Creating API endpoints with conflicting response fields

To debug in Tinybird:

1. Check Pipe node outputs for duplicate column names.
2. Verify Materialized View schemas for conflicts.
3. Use descriptive column names in Pipes.
4. Test Pipe outputs with simple queries first.

## See also

* [SQL Reference](/sql-reference) - SQL reference documentation
* [Working with Pipes](/forward/core-concepts/pipes)