Forum Discussion
Helper IMirrored Snowflake Database Storage
Hey Lanceometer ,
You have diagnosed it right, this is a source-side pattern, not a Fabric bug.
- Why storage grows: Fabric mirroring uses Snowflake Streams (CDC). A nightly full rebuild makes every row look new, so a fresh set of Parquet files gets written each cycle while older Delta versions stick around
- 1 day retention: It's only a threshold for when old files become eligible for cleanup, not guarantee that vacuum runs daily
- Manual VACUUM: Not supported on a mirrored database. Maintenance is handled internally (OPTIMIZE runs roughly every ~50 writes per table)
Next steps:
- Real fix: ask the Snowflake team to switch to incremental MERGE/UPDATE instead of a nightly rebuild
- Otherwise, skip mirroring for this table — use a OneLake shortcut or a pipeline load
- Keep retention at 1 day and give it a couple of cycles to plateau
Useful links:
Mirroring Snowflake in Fabric
VACUUM Delta tablesFound this useful? A quick Kudos goes a long way.
Got what you needed? Marking this as the Accepted Solution helps others land on the right answer faster when they search for the same thing
Super UserHi Lanceometer ,
Your suspicions are correct: if the table in Snowflake is fully rebuilt every night, the mirrored database CDC interprets everything as new, and the old files stay in storage until VACUUM runs based on the retention threshold.
That said, for this specific pattern (daily full reload at the source), Mirroring might not be the best fit, since it's designed for true incremental changes. Maybe it's worth considering two alternatives that align much better with your scenario:
- Copy Job with CDC from Snowflake, which relies on Snowflake's native change tracking: https://learn.microsoft.com/en-us/fabric/data-factory/cdc-copy-job-snowflake
- A classic Copy activity with the Snowflake connector, where you control the load logic yourself (truncate and load, overwrite, etc.) without depending on the mirrored database's internal retention mechanism: https://learn.microsoft.com/en-us/fabric/data-factory/connector-snowflake-copy-activity
Keep in mind that for incremental approaches (either CDC or watermark-based Copy activity) you'll typically need a reliable column to detect changes, such as a last modified date or an incremental key. Without it, you'd be limited to full loads.
If this helped, please consider giving it a Like. If it solved your issue, please mark it as the Accepted Solution to help others facing the same problem.
Thanks