The bronze layer holds raw data as it arrived from the source, with little or no change: the original columns, plus load metadata such as the source file and load time. Keeping raw data lets you reprocess it when a rule changes or a bug is found downstream. Bronze tables are usually append-only and are not meant for reporting.
For example, a retailer receives a CSV file of orders from each store every night. The bronze table for those files keeps every column from the file as it arrived, adds columns such as the source file name, the load time and a batch id, and appends one row per line of the file. If a file arrives twice, both copies are in bronze, and the duplicate is removed later on the way to silver. If a column is renamed upstream, the raw data is still there to reload with a corrected rule.
Bronze is also where a pipeline records what it could not read. A row whose date does not parse, or a file with a missing column, can be kept in a quarantine table with the reason, rather than silently dropped or allowed to break the load. Teams usually restrict who can read bronze, because raw data can hold values that later layers mask or remove, and because reports built on raw data tend to disagree with reports built on cleaned data.
On Databricks, bronze tables are usually Delta tables in a catalog and schema set aside for raw data; on Snowflake they are often tables loaded with COPY INTO; on Microsoft Fabric they live in a lakehouse in OneLake. The pattern is the same everywhere: land first, clean later, which is the ELT order.
It is the first step of the medallion architecture. In Emolysis, the Ingest (batch) shape lands data in bronze, typed and checked on load, so a malformed file is reported instead of half-loaded.