There are a couple of documented reasons why Airbyte’s “loaded records” count can be higher than what you see in the destination: 1.
Metrics are aggregated across retries/attempts On the Connection Timeline, Airbyte summarizes metrics (including “extracted” and “loaded” records) across
all attempts of a sync. If an attempt fails partway through extraction or loading and then is retried, the counts from the failed attempt are still included in the summary. This can make the “loaded records” number larger than what actually ended up committed in the destination. [[Connection timeline](
https://docs.airbyte.com/platform/cloud/managing-airbyte-cloud/review-connection-timeline#how-the-connection-timeline-reflects-failed-syncs)] 2.
“Data moved” is measured in protocol records, not destination rows Airbyte measures data volume and record counts based on the Airbyte Protocol messages in transit, which can differ from how your database stores or deduplicates data. This is why the UI’s numbers don’t always match a simple row count in the destination. [[Connection timeline](
https://docs.airbyte.com/platform/cloud/managing-airbyte-cloud/review-connection-timeline#data-volume-moved)] 3.
Rejected records (for activation destinations) If you are syncing into a
data activation destination (e.g., a SaaS tool) and some records don’t match the destination schema, they can be
rejected by the destination. Airbyte will still show them as processed, but they won’t appear in the destination; instead, they are written to a configured S3 bucket as “rejected records.” [[Rejected records](
https://docs.airbyte.com/platform/move-data/rejected-records)] For MongoDB specifically, the provided docs focus on CDC/oplog limitations and schema enforcement, but they do
not explicitly describe a case where MongoDB as a
destination would store fewer documents than the “loaded” count, beyond the general behaviors above. [[MongoDB troubleshooting](
https://docs.airbyte.com/integrations/sources/mongodb-v2/mongodb-v2-troubleshooting#connector-limitations)] To narrow this down in your setup, you can: - Check the
Connection Timeline for that sync and see if there were multiple attempts or partial failures. [[Connection timeline](
https://docs.airbyte.com/platform/cloud/managing-airbyte-cloud/review-connection-timeline#how-the-connection-timeline-reflects-failed-syncs)] - Confirm whether you’re using a
data activation destination and, if so, whether there are
rejected records logged and stored in S3. [[Rejected records](
https://docs.airbyte.com/platform/move-data/rejected-records)] If you share your connection type (source/destination and sync mode), I can help you interpret which of these explanations is most likely.