> 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/v1/data-admin/manage-lakehouse.md).

# Manage the Lakehouse

A **Lakehouse** delivers managed Apache Iceberg tables on cloud object storage, with a REST catalog, query services, and an auto-created Depot. As data admin you provision it and then own its structure and data.

## Provision

The Lakehouse is a `lakehouse` resource, applied through the DataOS CLI. It needs a Compute attached to the Tenant, reachable object storage (S3, ABFSS, or GCS), and a dedicated PostgreSQL database for the Iceberg catalog metastore.

{% hint style="info" %}
Creating a Lakehouse also means using a Compute, a Secret for the metastore, and a Secret for object storage. Each needs its own `Can Use` grant if you don't already hold one. Once the Lakehouse exists, resource-level access to it (`Can Edit`, `Can Manage Access`, `Can Use`) is granted and governed separately from the data inside it. See [Lakehouse: Access control](/operate/v1/access-model/resource-level-permissions/lakehouse-access-control.md) in the Access control section.
{% endhint %}

Create two Secrets first, one for the PostgreSQL metastore and one for object storage, then apply the Lakehouse manifest that references them:

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

The manifest names the compute, the metastore (PostgreSQL host, database, schema), and the storage backend (bucket, path, region). For the full manifest, per-backend storage blocks (S3, ABFSS, GCS), and tuning, see [Lakehouse](https://v2.dataos.info/references/dataos-resources/lakehouse) in the References.

{% hint style="warning" %}
Each Lakehouse must point at its own dedicated PostgreSQL database. The metastore stores metadata file locations for every Iceberg table under the Lakehouse; sharing one database across Lakehouses intermixes paths from different storage backends and breaks metadata operations. Multiple databases on one PostgreSQL server are fine, one per Lakehouse.
{% endhint %}

{% 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: lh-metastore-secret
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 the general Secret and Depot pattern, see [Add data sources and Secrets](/operate/v1/tenant-admin/add-data-sources-and-secrets.md#1-create-the-secret).
{% endstep %}

{% step %}

### Draft 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: v1alpha
type: lakehouse
description: Lakehouse on S3 storage
spec:
  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
    sparkCluster:
      server:
        requests:
          cpu: 200m
          memory: 512Mi
        limits:
          cpu: 500m
          memory: 1000Mi
      driver:
        coreLimit: "2048m"
        cores: 1
        memory: "2048m"
      executor:
        coreLimit: "2048m"
        cores: 1
        memory: "2048m"
        instances: 1
  logLevel: INFO
```

{% endcode %}

For the full attribute reference and per-backend storage blocks (S3, ABFSS, GCS), see [Lakehouse](https://v2.dataos.info/references/dataos-resources/lakehouse) in the References.
{% endstep %}

{% step %}

### Apply and verify

```bash
dataos-ctl resource apply -f lakehouse.yaml
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 the REST Catalog, query services, and Sherpa on the selected Compute. The Lakehouse is ready when all components report healthy and the auto-created Depot is available.
{% endstep %}
{% endstepper %}

## Structure data

Once the Lakehouse is active, you create and govern its namespaces, schemas, tables, and views through the Lakehouse interface. This is the day-to-day shape of the data: how it is organized, what is exposed, and how it evolves. For the command reference and table-format details, see the Lakehouse [command reference](https://v2.dataos.info/references/dataos-resources/lakehouse/command-reference) in the References.

## Operating practices

* **One database per Lakehouse**, as above. The most common Lakehouse failure traces back to a shared metastore database.
* **Name namespaces by domain or product**, consistently, so consumers and developers can find data without asking.
* **Plan storage layout** (bucket and relative path) before you provision; moving data later is costly.
* **Coordinate with developers.** Products built in Build read and write Lakehouse tables; align table structure with the products that depend on it rather than changing it under them.

Who can read and write this data is [access control](/operate/v1/data-admin/access-control.md); whether it is healthy is [monitoring](/operate/v1/data-admin/monitoring.md).


---

# 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/v1/data-admin/manage-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.