Fabric mirroring bills continuously for a Snowflake source that changes three times a day

Stopping and restarting the mirror is the first workaround anyone reaches for, and it does not behave like a scheduler. Support confirmed that a restart triggers a full reload instead of continuing from the previous CDC position, consistent with the public FAQ ^[6]. A timer around stop/start therefore buys a fresh copy of the table on every cycle ^[6]. Line those restarts up with the three source changes a day ^[4] and you are paying for 1,095 full reloads per table per year ^[1]. Turning off the service user does not work as a fallback timer: support explained that this falls outside supported scheduling mechanisms, and that connection retries and recovery become part of the problem ^[7].

Scale is the other half of it. The estate runs roughly 2,500 tables, and the author notes that maintaining an individual pipeline for each one would be a substantial burden, while adding that this is a concern about operational scale and does not mean every batch design needs a separate pipeline per table ^[10].

The second support case is the one that undercuts a green status. The first post described mirroring that looked healthy while the SQL analytics endpoint was not usable; this time the endpoint reads the data and Spark fails ^[2]. The error names the mismatch: "Parquet column cannot be converted ... Column: [AMOUNT], Expected: decimal(15,2), Found: INT32" ^[11]. The declared table schema and the physical encoding inside the file are different layers, and the failing read path did not reconcile the narrower file representation with the declared decimal type; the author records this as a read failure ^[12]. Source, table and file schemas were validated and the findings submitted to Microsoft support ^[19]. SQL succeeded on the data where the affected Spark read failed ^[13].

The fix is one session-level setting: spark.sql.parquet.enableVectorizedReader set to false for the affected read, then restored ^[15]. Microsoft's public guidance already lists the type-width issue and this Spark workaround ^[14]. Reads succeeded, and the team reported performance and capacity impact ^[16].

No throughput number comes with that report. The code in the post illustrates the configuration used and is not a benchmark or a reproduction executed for the article ^[17]. For the workaround to be affordable at this estate's size, the cost of non-vectorized reads would have to be measured on these tables and on the capacity actually paying for them, and that measurement is not in the account.

One thing in the write-up is worth copying regardless of platform: checked items describe experience or completed investigation, and unchecked items are labelled as future tests ^[20].