Beyond ‘COPY INTO’: Capturing, Logging, and Offloading Bad Data in Snowflake

Last Updated on September 25, 2026 by Editorial Team Author(s): Preethi Kaluva Originally published on Towards AI. Beyond ‘COPY INTO’: Capturing, Logging, and Offloading Bad Data in Snowflake If you’ve ever ingested raw CSVs from S3 into Snowflake for more than a few weeks, you’ve probably had a version of this moment where you load say 100 records and maybe 5-10 of them go missing. I learned the hard way that Snowflake’s COPY INTO can quietly report a successful load while silently dropping hundreds of thousands of schema-mismatched records without raising an error. If you regularly ingest raw CSVs from S3 into Snowflake, you've likely lost data this way too. Here is a repeatable, production-grade pattern to fix it for good. So let’s fix it properly, not with a Band-Aid, but with a repeatable, production-grade pattern you can drop into any pipeline. The Core Problem Here’s the naive ingestion flow most of us start with: S3 (raw files) → COPY INTO target_table → Done ✅ Looks fine on a whiteboard. In reality, source files are messy, a vendor changes a date format, a text field has an unescaped comma, someone exports a NULL as the literal string "NULL". When COPY INTO hits one of t…

≈