Roxanne Ricci and Adrien Chaussende, both data engineers at Back Market, published this on the Google Cloud blog on 5 December 2025. Read it as a vendor case study with their byline.
The marketplace connects more than 1,800 sellers of refurbished devices with buyers. The page says that since 2014 they have helped more than 17 million customers and count 2 million tons of CO2 avoided. The same page is where the IT story starts. The stack was on AWS, with Snowflake and Databricks in it. Workflows could write the same data to several destinations. Teams already read from BigQuery, so the other copies were expensive pipelines with no extra value. A small engineering team was collecting the debt.
They say they had recently moved all the data into BigQuery, and that BigQuery was already the enterprise data platform. Google Cloud was the managed-services choice after that. The B Corp commitment is the reason they give for liking Google Cloud’s carbon reporting and renewable-energy options. A long relationship with Google Cloud is the reason they give for moving the whole tech stack, not only the warehouse.
This project is the retirement, plus that wider move. It is the story that starts after the rows were already in BigQuery.
The Snowflake → BigQuery playbook assumes you still have to land tables, views, and grants. Back Market’s 2025 write-up starts later. Two earlier posts from the same engineering blog, and a 2026 interview, fill in pieces the case study skips.
The 2022 landing
On 18 February 2022 Ricci described an earlier warehouse move. Snowflake had been the first warehouse at the company, and she says the data team were its first customers. It had been a business enabler, and it had also grown without a governance plan. Cost was high. They could not see consumers clearly enough to lock down access. Reorganizing in place would have broken people.
The architecture she draws is a Delta Lake on S3, exposed in Snowflake through Airflow and Snowpipe. Some marketing and mobile data was already in BigQuery because of Google Analytics, and some teams were already moving infrastructure to Google Cloud. Delta tables on S3 were what made a warehouse swap possible without a second copy of the lake.
The requirements she lists are concrete. Data had to land in BigQuery. Data engineering would pay for storage, and each consuming team would pay for its own queries. S3 stayed the source of truth. They would ingest useful tables once, not everything, because AWS egress was the cost they were trying to hold down. The load had to be idempotent, monitored, and easy to rerun when a day was missing.
They picked Google Cloud’s Storage Transfer Service for the Parquet files. She says it was already integrated, it handled incremental loads, and it was free next to running a Spark cluster. The drawbacks she names are the black box of a scheduled transfer, and the lack of a native event trigger. So Airflow launched the transfers. Airflow was already running on Kubernetes, run by the infra team, and they already knew its limits. A shared cluster, batch orientation, and upgrades that depended on another team.
They did not let Airflow move the bytes. More than 300 tables would have meant that many DAGs doing real work. An API in a Docker image on Cloud Run did the S3, BigQuery, transfer, and Firestore calls. Airflow only called the API. She writes that this also made a later exit from Airflow smaller.
Governance was a second project, not a setting. Each source became two tables in a data-engineering GCP project. A staging table took the differential load, schema changes, and deduplication. A final table held the data. Each consuming team got its own GCP project and an authorized view onto the final table. The team paid for storage and technical jobs. The consumer paid for queries and saw only the columns in the view.
She says they picked beta consumers and started. The post is the design and the start. It does not report a finish date, a downtime window, or a row count. I would not treat “recently migrated” in the 2025 case study as a pointer back to this February design. The dates are years apart, and she never ties the sentences together.
The check that sat in front of turning Snowflake off
On 19 December 2022 Thibault Latrace wrote that the warehouse migration from Snowflake to BigQuery was recent, and that one blocker slowed the decommission. They needed to know which Tableau dashboards still used which Snowflake tables, so a dashboard would not break when the warehouse went away.
They bought that map instead of building it. Castor was the lineage and catalog tool. Snowflake and BigQuery could grant access to metadata, such as the query that built a table, without granting the data. Security audited those grants one by one.
Tableau could not. Latrace says there was no role for metadata without the underlying data, and they would not give an outside vendor dashboard read access. So they ran Castor’s own extractor, castor-extract-tableau, and uploaded the metadata themselves. A container built with Cloud Build ran daily as a Cloud Run job, on a Cloud Scheduler trigger, with secrets in Secret Manager. Terraform deployed it. Datadog watched it. The extract landed in a GCS bucket Castor owned.
That is a different gate from the 2025 double-run. Matching clone tables does not tell you which dashboard still points at Snowflake.
The two-week clone, then six months
The 2025 case study says they stood up a proof of concept in two weeks, with Google staff next to their own infra, database, data, security, and backend people. The goal was a clone of pre-production, running only on Google Cloud. They say they hit it. They picked some regions because those data centers run on renewable energy. No region names are on the page.
Production kept running on Databricks. The same data was written to clone tables in BigQuery. They compared the imports. When the outputs matched, they turned the old pipelines off.
Business users kept the same BigQuery screen, so the cutover did not change how they queried. The critical pieces were only on Google Cloud after six months. The page does not split those six months into a calendar.
BigQuery then holds sales, pricing, ecommerce, orders, delivery, supply chain, and product data, plus marketing-channel data for campaign reports. Analytics and data engineering track KPIs there, including IT carbon. Fewer boxes, they say, meant better observability, simpler permissions, fewer incidents, and faster onboarding. No incident count is attached.
The 90% is the CDC path
The pipeline they describe in detail is change data capture. It left AWS Database Migration Service for Google Cloud Datastream, and they say they kept a serverless shape.
Datastream writes a lot of small files per minute. Merging those into BigQuery one by one got expensive, so they batch the files once an hour, then load. The path they print is AlloyDB, through a proxy, into Datastream, then Cloud Storage. Cloud Composer runs the hourly transform on Kubernetes pods. BigQuery is the last stop. The page presents that as the finished flow. It does not tell the story of how the transactional databases arrived on AlloyDB.
They say Datastream alone lowered CDC costs by 90%. That is this pipeline, not a Snowflake contract.
Two other claims sit on the same page and point at different things. The headline says the move to Google Data Cloud halves data costs. The body says the integrated stack “cut our data processing speeds in half.” Cutting a speed in half is a slowdown. Cutting a duration in half is a speedup. The next sentence says queries run directly, so they stop paying for machines that have to start and then sit idle. I keep the headline, the speed sentence, and the 90% as three separate lines.
The bill the case study does not show
An April 2026 DataGen newsletter summarizes an interview with Matthieu, Analytics Engineering Manager at Back Market. This is a third-party write-up of a conversation, not the Google case study.
The newsletter says a recent company decision to leave Snowflake for BigQuery, and to put usage on GCP, caused a cost spike because BigQuery bills by the data a query scans. His team built a monitoring dashboard, named a cost owner per business vertical, and pushed clustering, partitioning, and incremental models. The quote they print is that the pain was useful, because it made them look at the model. There is no euro figure.
I read that spike and the case study’s “halves data costs” as different bills. One is analyst queries. The other is the platform story, with the only percentage attached to CDC. The pages never add them into one invoice.
The same interview says the current analytics stack is BigQuery, dbt, Tableau, OpenMetadata, Mergify on GitHub pull requests, and Airflow on the data-engineering side. A homemade tool that resembled dbt was replaced because it lacked tests and incremental runs. That stack is later than Ricci’s 2022 design, and the newsletter does not say which of those tools arrived during the 2025 cutover.
If your warehouse move still includes the first copy, the 2022 constraints are the ones aimed at that job. Egress, ingest once, and a view per consumer team. Their double-run only helps once a second writer is filling clone tables you can diff. And a Tableau workbook can still be pointed at the warehouse you are about to delete. The playbook is the unload and the grants. Use the case study for what they did after the copy existed, and for the habit of naming which 90% you mean.