Arquitectura Medallion explicada sin tecnicismos

El framework de tres capas que usan las mejores empresas de datos. Bronze, Silver y Gold: qué significa cada una y cómo implementarlo con un equipo pequeño y herramientas open-source.

Hay un concepto que estructura la mayoría de los proyectos de datos modernos y que, sin embargo, pocas empresas medianas conocen: la arquitectura Medallion.

El nombre suena técnico. La idea es simple. Y entenderla cambia cómo piensas la información de tu empresa.

¿Qué problema resuelve la arquitectura Medallion?

Imagina que tienes 5 sistemas distintos: ERP, CRM, sistema de logística, e-commerce, y un par de planillas de Excel que maneja ventas. Cada uno tiene sus propios formatos, sus propias convenciones de nomenclatura, sus propias reglas.

En el ERP, el cliente “Juan García” tiene el ID 4521. En el CRM, “J. Garcia” tiene el ID cliente-00892. En el sistema de e-commerce, “juan.garcia@empresa.com” es el identificador. Son el mismo cliente. Ninguno de los sistemas lo sabe.

Cuando alguien quiere saber cuánto compró Juan García en total, en todos los canales, tiene que hacer ese cruce manualmente. Y multiplica ese problema por miles de clientes, decenas de métricas y cinco sistemas que cambian constantemente.

La arquitectura Medallion resuelve ese problema con una estructura en capas. Cada capa tiene una responsabilidad específica, y el resultado final es un sistema donde los datos son confiables, auditables y útiles.

Las tres capas

Capa Bronze: los datos tal como llegan

La capa Bronze es el depósito de datos raw. Los datos se copian exactamente como están en cada sistema fuente, sin modificaciones. Si el ERP tiene un campo con formato de fecha inconsistente, en Bronze entra con ese formato inconsistente. Si hay duplicados, entran los duplicados.

¿Por qué no limpiar desde el inicio? Porque necesitas el historial completo para auditoría. Si en 6 meses alguien pregunta “¿por qué este cliente aparecía dos veces?”, puedes rastrearlo hasta la fuente original. Bronze es el registro inmutable de la realidad tal como era.

Bronze también actúa como buffer. Si un sistema fuente cambia su formato o deja de estar disponible, los datos históricos están en Bronze y no se pierden. Puedes reprocesar toda la cadena desde Bronze si necesitas cambiar las reglas de limpieza.

¿Qué hay en Bronze?

• Réplicas de las tablas del ERP, actualizadas diariamente (o cada hora)
• Archivos exportados del CRM
• Logs de transacciones del e-commerce
• Las planillas de Excel normalizadas a un formato estándar
• Cualquier API externa que alimente el negocio

Herramienta típica: Parquet en S3. Los archivos son baratos, duran para siempre, y cualquier herramienta puede leerlos.

Capa Silver: los datos limpios y cruzados

En Silver, los datos de Bronze se transforman: se limpian, se normalizan, se deduplican y se cruzan.

Es aquí donde “Juan García”, “J. Garcia” y “juan.garcia@empresa.com” se resuelven como el mismo cliente con un único ID maestro. Es donde las fechas inconsistentes se convierten a un formato único. Es donde los duplicados desaparecen. Es donde los datos de distintas fuentes empiezan a hablar el mismo idioma.

Silver no inventa información. Solo la ordena. Si hay un conflicto entre dos fuentes (el ERP dice que el pedido fue por $1.000 y el sistema de logística dice $950), Silver lo registra y aplica una regla de resolución predefinida, no lo adivina.

La diferencia clave con el proceso manual: estas reglas están escritas en código SQL, versionadas en Git, y se ejecutan automáticamente. No viven en la memoria de una persona. Si alguien cambia las reglas, el cambio queda registrado y se puede revertir.

¿Qué hay en Silver?

• Tabla única de clientes (con datos de todos los sistemas)
• Tabla única de productos (consolidando nomenclatura de ERP y e-commerce)
• Transacciones limpias y cruzadas con sus costos reales
• Historial completo sin duplicados

Herramienta típica: dbt (Data Build Tool). Permite escribir transformaciones en SQL estándar, con tests de calidad incorporados y documentación automática.

Capa Gold: los datos listos para el negocio

Gold es la capa que responde preguntas de negocio. Está construida sobre Silver y organiza los datos según cómo el negocio necesita verlos.

Si el negocio necesita saber la rentabilidad por zona geográfica, hay una tabla en Gold que calcula eso. Si necesita el ticket promedio por canal de venta, hay otra tabla. Si el equipo comercial necesita ver la evolución mensual de clientes activos vs. inactivos, Gold lo tiene pre-calculado.

Gold no es magia: es el trabajo de modelado de datos. Alguien con conocimiento del negocio y de SQL define qué métricas importan y cómo calcularlas. Ese trabajo se hace una vez. Después, cualquiera puede consultar Gold y obtener información consistente y confiable, sin importar qué herramienta use.

¿Qué hay en Gold?

• KPIs financieros: P&L, márgenes, flujo de caja
• KPIs comerciales: ventas por canal, retención, churn
• KPIs operativos: tiempos de entrega, tasa de devoluciones
• Dashboards y reportes conectados directamente

Herramienta típica: DuckDB para queries, Metabase o Power BI para los dashboards.

¿Por qué este diseño funciona mejor que los enfoques anteriores?

La arquitectura Medallion funciona porque separa responsabilidades claramente:

• Bronze se preocupa por la ingesta (¿llegaron los datos?)
• Silver se preocupa por la calidad (¿son correctos?)
• Gold se preocupa por el uso (¿son útiles?)

Cada capa puede evolucionar independientemente. Si Silver necesita una nueva regla de limpieza, no toca Bronze. Si Gold necesita una nueva métrica, no toca Silver ni Bronze.

Y lo más importante: cuando algo falla —y algo siempre falla eventualmente— sabes exactamente en qué capa buscar. Si los dashboards muestran un número raro, primero revisas Gold. Si el problema es de los datos crudos, bajas a Silver. Si es de ingesta, revisas Bronze.

Sin esta separación, un error en cualquier punto de la cadena puede propagarse silenciosamente hasta los reportes, sin que nadie sepa cuándo ni dónde entró.

¿Cómo se implementa en la práctica?

No es necesario un equipo de 20 ingenieros ni una infraestructura de millones de dólares.

Para una empresa mediana típica (5-10 fuentes de datos, 50-500GB de datos analíticos), la implementación estándar usa:

Capa	Herramienta	Costo
Ingesta	Scripts Python + Airbyte (open-source)	$0
Storage	Apache Parquet en S3	~$20-100/mes
Transformaciones	dbt (Data Build Tool)	$0
Orquestación	Dagster o Airflow	$0
Queries	DuckDB	$0
Reporting	Metabase o Power BI	$0-50/mes

Este stack es 100% open-source. El único costo recurrente significativo es el almacenamiento en S3. Para empresas medianas, es una fracción de lo que cuesta un analista dedicando tiempo a tareas manuales.

¿Cuánto tiempo lleva implementarlo?

En condiciones normales:

• Semanas 1-2: Conexión de fuentes y construcción de Bronze
• Semanas 3-4: Transformaciones Silver (limpieza, cruce, deduplicación)
• Semanas 5-6: Modelado Gold para los primeros casos de uso
• Semana 7 en adelante: Iteración — se agregan nuevas métricas y nuevas fuentes

El primer resultado concreto (un dashboard que reemplaza un proceso manual) aparece alrededor de la semana 6.

Errores comunes al implementar

Algunos errores que vemos repetidos en implementaciones que no funcionan:

Saltear Bronze: algunos equipos intentan limpiar los datos en el mismo paso que los ingresan. El problema es que pierden el histórico raw. Si seis meses después necesitan reprocessar con diferentes reglas, no pueden: los datos originales ya no existen.

Poner lógica de negocio en los dashboards: si la fórmula del margen bruto vive dentro de un dashboard de Power BI como campo calculado, esa lógica es invisible, no está testeada, y no está versionada. Cuando alguien la cambia sin avisar, todos los reportes cambian silenciosamente.

Sobre-diseñar Gold demasiado pronto: Gold debería responder preguntas específicas que el negocio ya tiene. Cuando se intenta construir una tabla Gold “universal” que responda todo, suele terminar siendo un monstruo lento que no responde bien nada en particular.

No documentar Silver: Silver es el cerebro del sistema. Si las reglas de resolución de conflictos, los criterios de deduplicación y las definiciones de métricas no están documentadas, el conocimiento vuelve a vivir en las personas en lugar de en el sistema.

¿Qué cambia después de implementarla?

Una vez que la arquitectura está funcionando, la dinámica de la información cambia en la empresa:

• El cierre mensual pasa de días a horas
• Las decisiones se toman sobre datos verificados, no sobre “lo que dice el Excel de ventas”
• Los pedidos de información ad hoc se resuelven en minutos, no en días
• El equipo puede construir nuevas métricas sin tocar los sistemas fuente
• Agregar un nuevo sistema al stack toma días, no semanas

La arquitectura Medallion no es un lujo para empresas grandes. Es la base que permite que los datos de una empresa mediana sean útiles.

Preguntas frecuentes

¿La arquitectura Medallion es lo mismo que un data warehouse?

No exactamente. Un data warehouse tradicional organiza los datos en un esquema rígido definido al ingreso (schema-on-write). La arquitectura Medallion, tal como se implementa hoy con Parquet + dbt + DuckDB, preserva los datos crudos en Bronze y aplica el esquema progresivamente. Es más parecido a un Data Lakehouse que a un warehouse clásico.

¿Puedo implementar Medallion encima de mi ERP actual?

Sí. El ERP sigue funcionando exactamente igual. La capa Bronze se construye extrayendo datos del ERP vía API, exportación programada o conexión directa a la base de datos. El ERP es una fuente más, no el destino.

¿Qué pasa si tengo datos en Google Sheets y Excel además de sistemas formales?

Google Sheets y Excel son fuentes válidas. Se pueden ingestar automáticamente (Google Sheets tiene API; Excel puede procesarse con scripts). En Bronze entran como archivos normalizados. La capa Silver aplica las mismas reglas de limpieza que a cualquier otra fuente.

¿Esta arquitectura escala si la empresa crece?

Sí. La arquitectura está diseñada para escalar de forma incremental: se agregan nuevas fuentes a Bronze sin tocar lo existente, se agregan nuevas transformaciones a Silver, se agregan nuevos modelos a Gold. Cuando el volumen crece por encima de lo que DuckDB puede manejar en single-node, se puede migrar el motor de consulta a Trino o Spark sin cambiar los archivos Parquet ni el código dbt.

---

Si tu equipo pasa tiempo consolidando datos manualmente en vez de analizarlos, agenda una llamada. En 30 minutos te mostramos cómo aplicamos esta arquitectura a tu caso concreto.