---
title: "Bronze Silver Gold en data lake: guía 2026"
description: "Cómo construir arquitectura Bronze, Silver, Gold en un data lake en 2026: convenciones, dbt, vistas materializadas, errores comunes y caso real LATAM."
slug: "como-construir-bronze-silver-gold-layer-en-data-lake"
url: "https://catalizadora.ai/blog/como-construir-bronze-silver-gold-layer-en-data-lake"
cluster: "datos-sistemas/construir-bronze-silver"
author: "Pablo Estrada"
published_at: "2026-06-17T05:18:47.138814+00:00"
updated_at: "2026-06-19T19:59:51.42746+00:00"
read_minutes: "5"
lang: "es"
---
# Bronze Silver Gold en data lake: guía 2026

> Cómo construir arquitectura Bronze, Silver, Gold en un data lake en 2026: convenciones, dbt, vistas materializadas, errores comunes y caso real LATAM.

Para construir arquitectura Bronze, Silver, Gold en un data lake en 2026 necesitás tres capas con propósito distinto: **Bronze preserva datos crudos como llegan, Silver normaliza y limpia para consulta del equipo de datos, Gold pre-calcula para BI ejecutivo**. Las orquestás con dbt (SQL-first) o Dagster (Python heavy), con tests de unicidad y no-nulos en cada capa, y lineage automático que te dice qué se rompe cuando cambia algo arriba. En una distribuidora cliente nuestra entregamos 73 gold tables normalizadas en 12 semanas sobre 13 millones de filas legacy migradas.

## ¿Qué es exactamente Bronze, Silver, Gold y por qué importa?

El patrón Bronze/Silver/Gold (también llamado medallion architecture, popularizado por Databricks) resuelve los tres roles esenciales que cualquier data lake serio debe cumplir:

**Bronze** preserva. Es la capa de datos crudos como llegan de los sistemas fuente. Sin transformación. Sin deduplicación. Sin limpieza. Si SQL Server tenía un campo con tipo equivocado, Bronze lo refleja tal cual. La razón es auditabilidad y reprocesamiento: si descubrís un bug en Silver, regenerás desde Bronze sin perder originales.

**Silver** normaliza. Es la capa de datos limpios, deduplicados, con tipos correctos y joins de referencia aplicados. Tu equipo de datos consulta Silver para análisis ad-hoc, modelado, validación de hipótesis. La unicidad es no negociable: una orden tiene un id, un cliente tiene un id, sin duplicados.

**Gold** decide. Es la capa de tablas pre-calculadas listas para BI y reportería ejecutiva. KPIs precomputados, agregados por dimensión, vistas materializadas con refresh programado. Es lo que conecta tu dashboard.

Si te saltás Bronze, perdés auditabilidad. Si te saltás Silver, tu BI lee data sucia. Si te saltás Gold, tu dashboard hace queries pesadas sobre Silver cada vez y se vuelve lento.

## Convenciones de nomenclatura y esquemas

La convención más limpia en 2026 sobre Postgres:

```sql
CREATE SCHEMA bronze;
CREATE SCHEMA silver;
CREATE SCHEMA gold;

-- Bronze: espejo del sistema fuente
CREATE TABLE bronze.sap_b1_oitm (
  itemcode TEXT,
  itemname TEXT,
  source_extracted_at TIMESTAMPTZ,
  source_file TEXT
);

-- Silver: normalizado
CREATE TABLE silver.products (
  product_id UUID PRIMARY KEY,
  sku TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  source_system TEXT,
  created_at TIMESTAMPTZ,
  updated_at TIMESTAMPTZ
);

-- Gold: agregado de decisión
CREATE MATERIALIZED VIEW gold.sales_by_product_month AS
SELECT 
  product_id,
  date_trunc('month', sale_date) AS month,
  SUM(amount) AS total_sales,
  COUNT(*) AS orders
FROM silver.sales
GROUP BY 1, 2;
```

Las tablas Bronze llevan prefijo del sistema fuente (`bronze.sap_b1_*`, `bronze.hubspot_*`). Las Silver llevan nombres limpios de entidad de negocio (`silver.products`, `silver.customers`). Las Gold llevan nombre de KPI o vista de decisión (`gold.sales_by_product_month`, `gold.pipeline_active`).

## Orquestación con dbt: el estándar 2026

dbt (data build tool) es el estándar de facto para orquestar transformaciones Bronze a Silver a Gold cuando tu stack es SQL-first. Estructura de proyecto:

```
models/
  bronze/
    sources.yml  -- define fuentes
  silver/
    products.sql -- transforma bronze a silver
    customers.sql
  gold/
    sales_by_product_month.sql -- agrega silver a gold
tests/
  unique_product_id.sql
  not_null_sku.sql
```

dbt te da: tests declarativos (unicidad, no nulos, valores aceptados), lineage automático (qué Silver depende de qué Bronze), documentación auto-generada (`dbt docs`), refresh incremental (sólo procesa filas nuevas), y CI/CD integrado.

Para Python-heavy transformations (Pandas, PySpark, ML features), Dagster o Prefect orquestan mejor. La regla: declarativo, con tests, reproducible.

## Cómo decidir qué va en Silver y qué va en Gold

La regla que funciona:

- **Silver** = atómico, normalizado, granular. Una fila por entidad de negocio (orden, cliente, producto, factura). Lo consulta el equipo de datos.
- **Gold** = agregado, precomputado, dimensional. Una fila por combinación de dimensiones (mes × sucursal × producto). Lo consulta el CEO en un dashboard.

Pregunta operativa: ¿quién consulta esto? Si un analista hace SQL ad-hoc, va a Silver. Si un director general lo ve en un dashboard ejecutivo, va a Gold.

## El caso real: 73 gold tables en 12 semanas

En una distribuidora cliente nuestra (control de plagas, 100 franquicias multi-país) implementamos Bronze/Silver/Gold sobre Supabase:

- **Reto**: 13 millones de filas legacy en SQL Server 2019 con 197 tablas inconsistentes.
- **Bronze**: 197 tablas snapshot legacy, 1.17 TB en GCS bronze parquet, 2.7 GB bronze parquet activo en Supabase Storage.
- **Silver**: 825 silver views normalizadas, deduplicadas, con tipos correctos.
- **Gold**: 75 gold materialized views más 73 gold tables finales.
- **Verificación**: triple chequeo source = bronze = silver = gold.
- **Seguridad**: 57 RLS policies, 17 roles RBAC.

Resultado: 3.6 millones de filas migradas a Supabase en 48 horas con verificación fila-a-fila. 100 franquicias operativas en 12 semanas. Inversión total 26,000 USD pago único. Lo que antes tomaba 30 ingenieros y 18 meses lo entregamos en semanas.

## Errores comunes que matan un data lake

1. **No tener Bronze**: cargás directo de fuente a Silver. Cuando hay bug, no podés reprocesar. Y siempre hay bugs.
2. **Silver y Gold mezclados**: el equipo de datos consulta Gold para análisis ad-hoc, contamina la capa de decisión.
3. **Sin tests dbt**: un campo cambia de tipo en fuente y Silver se rompe silencioso. Tu dashboard muestra ceros por una semana.
4. **Sin lineage**: nadie sabe qué Gold depende de qué Bronze. Cambian un campo upstream y se rompe todo.
5. **Vistas materializadas sin refresh**: Gold queda con data vieja, dashboard miente.
6. **Sin RLS o RBAC**: cualquiera ve todo. En multi-tenant es de cárcel.

## Próximos pasos

Si tenés data en 5 sistemas o más sin unificar, arrancá con un workshop de 1 día sobre la arquitectura y diseñá el blueprint. Si querés data lake como parte de transformación operativa completa con sistema construido encima, agendá una llamada de 30 minutos sobre tu operación.

- [MAGIA Core](https://catalizadora.ai/magia/core) si querés data lake unificado Bronze/Silver/Gold más sistema a medida en 12 semanas.
- [MAGIA Forge](https://catalizadora.ai/magia/forge) si tu operación requiere multi-tenant con IA y guardrails sobre data lake.

Sin retainers, sin licencias atadas, código a tu nombre.
## Preguntas frecuentes

### ¿Qué significa exactamente Bronze, Silver, Gold en un data lake?

Bronze son datos crudos como llegan de los sistemas fuente, sin modificación. Silver son datos normalizados, deduplicados y con tipos correctos. Gold son tablas de decisión listas para BI y reportería ejecutiva. Es el patrón medallion arquitectura que Databricks popularizó, aplicable a cualquier data lake.

### ¿Por qué tres capas y no dos o cuatro?

Tres capas resuelven los tres roles esenciales: preservar (Bronze para auditabilidad y reprocesamiento), normalizar (Silver para consulta del equipo de datos), decidir (Gold para BI ejecutivo). Cuatro capas agregan complejidad sin ganancia clara; dos pierden la preservación cruda.

### ¿Qué herramienta uso para orquestar las transformaciones?

dbt es el estándar de facto en 2026 para SQL-first. Para Python heavy, Dagster o Prefect. Para batch puro, Airflow sigue siendo válido. La regla es: declarativo, con tests, lineage automático y reproducibilidad. Si tu transformación no se puede regenerar desde Bronze, no es Silver.

### ¿Cómo decido qué va en Silver y qué va en Gold?

Silver es atómico (orden, cliente, producto, factura) normalizado. Gold es agregado o pre-calculado para decisión (ventas por mes por sucursal, embudo de conversión, pipeline activo). Si lo consulta el equipo de datos, va en Silver. Si lo consulta el CEO en un dashboard, va en Gold.

### ¿Cuánto tarda construir Bronze, Silver, Gold para una empresa mediana?

Para una empresa mediana con 5 a 10 sistemas fuente y 100 GB a 2 TB de datos: entre 6 y 12 semanas con un equipo serio. Lo que antes tomaba 30 ingenieros y 18 meses lo entregamos en semanas. Una distribuidora cliente nuestra entregó 73 gold tables normalizadas en 12 semanas.


---

Source: https://catalizadora.ai/blog/como-construir-bronze-silver-gold-layer-en-data-lake
Author: Pablo Estrada — AI Catalyst, LLC (catalizadora.ai)