> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/phase-3-configure-tenant-with/lakehouse.md).

# Lakehouse

A **Lakehouse** delivers managed Apache Iceberg tables on cloud object storage with a REST Catalog, query services (Spark Cluster and Sherpa), and an auto-created Depot. The Operator or Tenant Admin provisions it through the DataOS CLI.

Lakehouse setup requires two Secrets before you apply the Lakehouse manifest: one for the PostgreSQL metastore and one for object storage. For external warehouse or database connections, use [Data source access](/operate/phase-3-configure-tenant-with/data-source-access.md) instead.

{% hint style="info" %}
Deep dive: [Lakehouse concepts](/concepts/resources/lakehouse.md)
{% endhint %}

***

## When to use this

| Goal                                                   | Resource                                                                           |
| ------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| Managed Iceberg on S3, ABFSS, or GCS with REST Catalog | **Lakehouse** (this guide)                                                         |
| Connect to an existing warehouse or database via UDL   | [Data source access](/operate/phase-3-configure-tenant-with/data-source-access.md) |

***

## Prerequisites

* **Compute** attached to the tenant (`spec.compute`)
* **Object storage** reachable from the dataplane (S3, ABFSS, or GCS)
* **PostgreSQL** for the Iceberg JDBC catalog metastore — each Lakehouse must point to a dedicated, isolated database
* DataOS CLI permission to create Lakehouse and Secret resources

Backend guides: [S3](/concepts/resources/lakehouse/supported-sources.md) · [ABFSS](/concepts/resources/lakehouse/supported-sources.md) · [GCS](/concepts/resources/lakehouse/supported-sources.md)

{% hint style="warning" %}
**Each Lakehouse must point to a dedicated, isolated PostgreSQL database.** Do not reuse the same PostgreSQL database across multiple Lakehouses.

The PostgreSQL metastore stores the metadata file locations for every Iceberg table registered under a Lakehouse. If two Lakehouses share the same database, the metastore intermixes metadata paths from both storage backends — causing metadata operations to fail when a scan returns file paths the current storage secret cannot access.

You can host multiple databases on the same PostgreSQL server. Each Lakehouse must reference its own dedicated database.
{% endhint %}

***

## Steps

{% stepper %}
{% step %}

### Create secrets

Create two Secrets before the Lakehouse manifest: one for PostgreSQL and one for object storage.

{% tabs %}
{% tab title="Metastore (PostgreSQL)" %}
{% code title="metastore-secret.yaml" %}

```yaml
name: ${metastore-secret-name}
version: v2alpha
type: secret
description: PostgreSQL metastore secret for Lakehouse.
secret:
  type: key-value
  data:
    username: "${postgres-username}"
    password: "${postgres-password}"
```

{% endcode %}
{% endtab %}

{% tab title="Storage (S3)" %}
{% code title="storage-secret.yaml" %}

```yaml
name: lh-storage-secret
version: v2alpha
type: secret
layer: user
description: S3 storage secret for Lakehouse.
secret:
  type: key-value
  data:
    aws_access_key: "${aws-access-key}"
    aws_secret_key: "${aws-secret-key}"
    storage_type: "s3"
```

{% endcode %}
{% endtab %}
{% endtabs %}

Apply both Secrets before you apply the Lakehouse manifest:

```bash
dataos-ctl resource apply -f metastore-secret.yaml
dataos-ctl resource apply -f storage-secret.yaml
```

For ABFSS and GCS Secret formats, see [Create secrets in Lakehouse concepts](/concepts/resources/lakehouse.md#create-the-required-secrets). For the general pattern, see [Secret](/operate/phase-3-configure-tenant-with/data-source-access.md#create-the-secret) and [Depot](/operate/phase-3-configure-tenant-with/data-source-access.md#create-the-depot).
{% endstep %}

{% step %}

### Draft the Lakehouse manifest

Replace the placeholders with your environment values. This example uses S3. Use the matching `storage` block for ABFSS or GCS.

{% code title="lakehouse.yaml" %}

```yaml
name: s3pglh
version: v2alpha
type: lakehouse
description: Lakehouse on S3 storage
spec:
  type: iceberg
  compute: "${compute-name}"
  runAsUser: "${user-id}"
  iceberg:
    metastore:
      type: iceberg-jdbc-catalog
      replicas: 1
      secret: "${tenant}:lh-metastore-secret"
      postgresql:
        host: "${postgres-host}"
        port: "5432"
        database: "${database-name}"
        schema: public
      resources:
        limits:
          cpu: "1"
          memory: 2000Mi
        requests:
          cpu: "1"
          memory: 1000Mi
    storage:
      type: s3
      s3:
        bucket: "${s3-bucket-name}"
        relativePath: "${relative-path}"
        region: "${aws-region}"
        format: ICEBERG
      secret: "${tenant}:lh-storage-secret"
    sherpa:
      replicas: 1
      resources:
        limits:
          cpu: 500m
          memory: 1000Mi
        requests:
          cpu: 200m
          memory: 512Mi
  logLevel: INFO
```

{% endcode %}

| Field                   | Description                                                          |
| ----------------------- | -------------------------------------------------------------------- |
| `spec.compute`          | Compute Resource attached to the Tenant                              |
| `spec.runAsUser`        | DataOS user ID that runs Lakehouse operations                        |
| `spec.iceberg.*.secret` | Tenant-qualified Secret reference in `<tenant>:<secret-name>` format |
| {% endstep %}           |                                                                      |

{% step %}

### Apply the manifest

```bash
dataos-ctl resource apply -f lakehouse.yaml
```

{% endstep %}

{% step %}

### Verify creation

```bash
dataos-ctl resource get -t lakehouse
dataos-ctl resource get -t lakehouse -n s3pglh -d
```

DataOS creates an auto-named Depot (`<lakehouse-name>-depot`) and provisions REST Catalog, Flare, and Sherpa on the selected compute.

{% hint style="success" %}
The Lakehouse is ready when all components report healthy and the auto-created Depot is available.
{% endhint %}
{% endstep %}
{% endstepper %}

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/operate/phase-3-configure-tenant-with/lakehouse.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.