What does Airbyte write into its raw destination tables before typing and deduping?

## Two stages, two tables A destination write in modern Airbyte is not one operation. Records first land verbatim in a **raw table**, then a second step turns them into the **final table** consumers query. Understanding the split explains most of the confusing things people see in a destination: duplicate rows that are supposed to be deduplicated, an unfamiliar schema full of underscore-prefixed columns, and a sync that succeeded while one field arrived null. ## The raw table Raw tables live in an Airbyte-managed schema, `airbyte_internal` by default, and the schema name is configurable in the destination settings. Each row carries the record as a JSON document plus metadata: - `_airbyte_raw_id` — a generated identifier for the raw record. - `_airbyte_extracted_at` — when the source emitted the record. This is the timestamp deduplication uses to break ties and the one you filter on when reading snapshots from a full-refresh-append stream. - `_airbyte_loaded_at` — set when the typing step has consumed the row; a null value means it is still pending. - `_airbyte_data` — the record payload as JSON. The raw table is strictly append-only within a sync and tolerates everything: boundary re-reads, retry replays, records whose types do not match the declared schema. That tolerance is the point — landing first and interpreting second means a schema surprise cannot destroy the extraction. ## The final table The final table is what you name in the connection's destination namespace, with real typed columns derived from the stream's schema. For deduped streams it holds one row per primary key; for append streams it holds everything. It also carries `_airbyte_meta`, a structured column recording per-row problems the typing step hit. That last column is the one worth remembering. If a field declared as a number arrives as the string `"n/a"`, Airbyte does not fail the sync and does not silently discard the record. It writes the row with that field unset and notes the problem in `_airbyte_meta`. The practical consequence: a green sync is not evidence that every value survived typing, and a quality check that never inspects `_airbyte_meta` will not notice a source that started sending garbage in one field. ## Why the split exists Historically, Airbyte destinations wrote a raw table and then ran a separate **basic normalization** step, implemented with dbt, to produce the typed and deduplicated tables. That approach coupled the destination to a transformation runtime, was slow on large streams, and failed the whole sync on a type mismatch. It was replaced by destination-native typing and deduplication executed by the destination's own SQL engine, which is faster, does not require dbt, and degrades per-row rather than per-sync. Which of the two a given deployment does depends on its version and destination — worth stating as an assumption rather than asserting. ## How this should change what you do Point downstream models at the final table. Reading the raw table directly means parsing JSON yourself, inheriting the duplicates that deduplication exists to remove, and coupling your models to an internal layout Airbyte is free to change between releases. Do budget for the raw table, though. It grows with every record ever landed for the stream, so its storage cost is real and it is a legitimate target for a retention policy — bearing in mind that clearing raw data undermines the ability to rebuild the final table without a full re-read. And watch the second stage as a cost centre. Typing and deduplication is work the destination warehouse performs on every sync, scaling with the volume landed. A stream synced very frequently with a large key space can spend more compute rebuilding its final table than extracting from the source — a real reason to sync some streams less often rather than more. ## In an interview Describe the two stages and the reason for the ordering: land untyped so extraction cannot be poisoned by a schema surprise, then interpret with per-row error capture instead of per-sync failure. Naming `_airbyte_extracted_at` and `_airbyte_meta` and their uses is enough detail; reciting the whole layout is not the point, and the layout is version-dependent.