How Aeyde made Looker dashboards load in seconds, cut data infrastructure costs by 77%, and rebuilt trust in their numbers

The client

Aeyde is a Berlin-based footwear and accessories brand for women, founded in 2015. Made in Italy, they sell direct-to-consumer on Shopify and B2B to retailers worldwide. Their data platform supports both sides of the business: D2C marketing and merchandising, plus B2B operations and reporting.

The challenge

By April 2024, Aeyde's data stack was creating growing complexity and performance bottlenecks. The platform had grown organically since 2019 — Panoply for ingestion and warehousing, dbt for some transformations, Looker for BI — and complexity had grown faster than the team could manage it.

The visible symptoms were everywhere:

• Heavy dashboards took minutes to load. Some failed to load more than a few months of historical data at all.
• Looker schedules failed regularly because they timed out before completing.
• Dashboards stalled mid-render because the query queue was saturated by other slow queries running in the background.
• KPI definitions lived in dozens of LookML derived tables, often duplicated, sometimes inconsistent. Updating a metric meant tracking down every instance.
• Adding a new data source could take days of work.

Behind the symptoms, the underlying technical reality was a stack pushed past its design:

• Panoply (built on Redshift) was a black box — costly at $1,300/month, slow to query, opaque when things broke, and hitting storage limits.
• dbt held about 30% of the transformation logic. The rest lived in LookML.
• Looker carried 119 derived tables (64 SQL-based, 55 LookML-native). Some explores joined 50+ views. A simple business question could compile into a 500-line query.

Aeyde's BI Lead, Phoebe, knew it was the right time to audit the data stack and evolve it to better support the company's continued growth. With maternity leave approaching, the team also needed someone to step in during her absence and help drive that transition forward.

The approach

Two principles guided the engagement.

Clean before migrating.

Most consultants would have proposed jumping straight to a new stack. We didn't. The stack had real problems, but it also contained unused assets, redundant models, and outdated schedules. Migrating that complexity to a new stack would simply move the problem. We cleaned first.

Most consultants would have proposed jumping straight to a new stack. We didn't.

Keep transformation logic in one place.

Logic split across LookML and dbt creates inconsistency and duplication. We consolidated everything into a single transformation layer — first dbt, then Dataform after the migration — with a layered architecture (staging → intermediate → mart → report). Looker became the consumption layer, not a transformation engine.

This meant a three-phase plan, not a single migration project.

What we built

Phase 1: Cleaning the existing stack

Before touching anything new, we audited and pruned the existing setup. In Panoply: deleted 38 unused connections and the unused tables they fed. In dbt: removed obsolete models and renamed the rest with consistent conventions. In Looker: deleted inactive accounts, audited 1,013 looks and 340 dashboards (only 23% and 12% respectively were used in the last 30 days), disabled auto-refresh on dashboards that didn't need it, and redistributed 98 schedules across the day instead of all firing between 4–6am.

Phase 2: Pre-transforming data with dbt

The performance problem in Looker wasn't really a Looker problem — it was a "data is being transformed at query time" problem. We moved the heavy lifting into dbt. We restructured dbt around a layered architecture: staging models for 1:1 source cleaning, intermediate models for joins within a domain, marts for cross-domain business logic, reports for aggregated tables.

We started with the most complex Looker explore (Sales — Commercial view at line level, joining 53 underlying views) and pre-built every derived table as a proper dbt model. Joins that Looker used to compute on the fly — Shopify customer/address/tax/discount data joined to order lines — were now pre-computed in dbt. Looker explores were rebuilt against the new pre-built tables. Then we repeated the pattern across the rest of the explores, in priority order.

By the end of Phase 2, derived tables in Looker dropped from 119 to 0. All transformation logic lived in dbt.

Phase 3: Migrating to BigQuery and modernizing the stack

With logic centralized and Looker simplified, the migration was the cleanest part. We replaced Panoply with Airbyte for ingestion (transparent, far cheaper) and BigQuery as the warehouse. A few Python Cloud Run Jobs covered the few unconventional sources Airbyte didn't have a connector for. Native BigQuery integrations replaced the rest: GA4 via the native export, Google Ads via the BigQuery Data Transfer Service, and Google Sheets via external tables — all landing in BigQuery directly. dbt was migrated to Dataform to consolidate on the Google Cloud ecosystem. Looker's database connection was switched to BigQuery, and the legacy Panoply stack was decommissioned.

The new stack had four pieces — Airbyte, BigQuery, Dataform, Looker — replacing Panoply + Stitch + make.com → S3 + dbt + Looker. Less surface area, less to maintain, less to break.

Results

Dashboards that used to take minutes load in seconds. The Looker schedules that kept failing run reliably. The query queue isn't saturated anymore because queries return fast enough to clear. KPI definitions live in one place — Dataform — instead of scattered across 119 LookML derived tables. Editing a KPI or adding a source went from a multi-day project to a half-hour exercise for routine changes, a few hours for complex ones.

The infrastructure cost dropped from $1,300/month (Panoply) to about $300/month (Airbyte + BigQuery), a 77% reduction. The team has visibility and control they never had with Panoply's black-box backend. The team trusts the numbers again — because the logic that produces them is centralized, reviewable, and consistent.

The collaboration continues on smaller items as Aeyde's data needs evolve.