Looker vs D23.io: When LookML Stops Being Worth the Lock-In

Table of Contents

1. Executive Summary: The Lock-In Problem
2. What Is LookML and Why It Matters
3. The D23.io Approach: Open-Source Semantics
4. Pricing and Total Cost of Ownership
5. Semantic Governance: LookML vs dbt + Superset
6. Migration Effort and Timeline
7. Real-World Decision Framework
8. When to Stay with Looker
9. When to Move to D23.io
10. Next Steps and Implementation

---

Executive Summary: The Lock-In Problem {#executive-summary}

Australian enterprises face a critical inflection point when evaluating business intelligence platforms. Looker—Google Cloud’s premium BI tool—has dominated the mid-market and enterprise segment for years, but its proprietary LookML language and steep pricing have created significant lock-in costs that now rival the value it delivers.

D23.io’s modern alternative stack (Apache Superset + dbt + semantic layer governance) offers a fundamentally different proposition: portability, cost efficiency, and alignment with contemporary data engineering practices. For many organisations, the question is no longer “Is Looker good?” but rather “Is Looker’s lock-in worth what we’re paying?”

This guide walks through the technical, financial, and operational dimensions of that decision. We’ve worked with Australian startups and mid-market operators who’ve made both choices, and the data is clear: lock-in costs matter more than feature parity when you’re evaluating a 3–5 year commitment.

---

What Is LookML and Why It Matters {#what-is-lookml}

The Proprietary Language Problem

LookML is Looker’s proprietary modelling language, designed to define business logic, dimensions, measures, and relationships between data tables. On the surface, this sounds reasonable: a domain-specific language (DSL) built for analytics.

The problem emerges when you realise that LookML expertise is only valuable inside Looker. Your data engineers and analysts invest months learning a syntax, patterns, and conventions that have zero transferability. Unlike SQL, Python, or even dbt’s YAML-based approach, LookML knowledge doesn’t compound across your organisation’s broader data stack.

When we’ve helped Australian enterprises evaluate alternatives, the LookML lock-in often represents 30–40% of the total switching cost. Your team has spent two years building 200+ LookML models. Those models don’t port cleanly to other platforms. You can’t easily extract the business logic and redeploy it elsewhere.

How LookML Works in Practice

LookML files define:

• Views: Logical tables that map to database tables or derived tables
• Dimensions: Attributes (e.g., customer_id, region, date)
• Measures: Aggregations (e.g., SUM, COUNT, AVG)
• Explores: The entry points users interact with (pre-built question templates)
• Dashboards: Visualisations and tiles built from Explores

The workflow is familiar to BI practitioners: define your semantic model once, then users query it via the Looker UI without touching SQL. Looker compiles LookML into optimised database queries.

But here’s the catch: if you want to move that semantic model to another platform, you’re rebuilding from scratch. There’s no “export to dbt” button. There’s no standardised translation. You’re manually rewriting business logic in a new language.

---

The D23.io Approach: Open-Source Semantics {#d23io-approach}

What D23.io Actually Is

D23.io isn’t a single product—it’s a consulting-led approach to modern data stacks built around three open-source and semi-open components:

1. Apache Superset: Open-source BI and data visualisation platform (similar to Looker’s UI layer)
2. dbt (data build tool): Open-source transformation framework for SQL-based data modelling
3. Semantic Layer: A governance and abstraction layer (via dbt’s semantic layer or third-party tools) that sits between raw data and visualisations

The philosophy is radically different from Looker’s monolithic approach. Instead of buying a closed ecosystem, you’re assembling best-of-breed open components and building your own stack.

When we work with Australian operators on AI Strategy & Readiness, we often find that this modular approach aligns better with modern platform engineering practices. Your data stack becomes part of your broader engineering culture, not a separate silo controlled by a vendor.

Why the Stack Matters More Than Individual Tools

Superset alone isn’t a Looker replacement. It’s a capable BI tool, but it lacks Looker’s polish and some advanced features. However, when paired with dbt for semantic governance and transformation, the stack becomes genuinely competitive.

Here’s why: dbt has become the industry standard for data transformation, and it’s language-agnostic. You model your data in SQL (or Python, via dbt Python models). That SQL is portable. If you leave dbt tomorrow, your transformation logic doesn’t evaporate—it’s just SQL sitting in a Git repository.

The semantic layer—whether via dbt’s native layer, Cube.js, or another tool—provides the abstraction that LookML tries to offer. But it’s built on open standards, not a proprietary DSL.

Real-World D23.io Deployment

We’ve seen a $50K D23.io engagement deliver Apache Superset rollout with architecture, SSO, semantic layer, dashboards, and training in 6 weeks. That’s not a coincidence. The modular approach means you can scope work more tightly, iterate faster, and avoid the months-long implementation cycles Looker often requires.

For Australian mid-market companies, this matters. You’re not waiting for a Looker partner to allocate resources. You’re working with a focused team that knows the stack inside out and can ship fast.

---

Pricing and Total Cost of Ownership {#pricing-tco}

Looker’s Pricing Model

Looker pricing is opaque and bespoke, but typical enterprise deployments run:

• Viewer licenses: AU$300–500 per user per year (read-only access)
• Developer licenses: AU$800–1,500 per user per year (can build content)
• Minimum seat commitments: Often 20–50 seats, regardless of actual usage
• Annual increases: 3–5% year-on-year, compounded

For a 100-person organisation with 50 Viewer seats and 10 Developer seats, you’re looking at AU$40K–60K per year, minimum. Over three years, that’s AU$120K–180K, before implementation, training, or customisation.

Then add:

• Implementation: AU$50K–150K (Looker partner fees, often AU$200–300/hour)
• Ongoing support: AU$10K–30K per year (managed services or dedicated support)
• Training and enablement: AU$5K–20K (internal time + external facilitation)

Total three-year Looker cost: AU$185K–280K+ for a mid-sized organisation.

D23.io’s Cost Structure

D23.io uses a different model:

• Apache Superset: Free (open-source) or AU$5K–20K per year if you want managed hosting
• dbt: Free (open-source) or AU$3K–15K per year for dbt Cloud (managed orchestration and testing)
• Semantic layer: Free (dbt native) or AU$0–10K per year for third-party tools
• Consulting: AU$150–250/hour, typically AU$30K–80K for initial implementation
• Ongoing support: AU$5K–15K per year (self-managed or light managed services)

Total three-year D23.io cost: AU$95K–165K for equivalent functionality.

The real win isn’t just the lower absolute cost—it’s the predictability and portability. You’re not locked into annual license increases. You can downgrade or switch tools without losing your data models. Your team’s skills are transferable.

Hidden Costs of Lock-In

When evaluating Looker vs D23.io, most organisations miss the hidden costs of lock-in:

1. Switching cost: If you leave Looker after 3 years, you’ll spend AU$30K–60K rebuilding your semantic model elsewhere
2. Talent cost: Hiring data engineers who know LookML is harder than hiring SQL/dbt experts. You may pay a 10–15% premium for LookML specialists
3. Opportunity cost: Your team spends time maintaining LookML instead of building data products or automation
4. Feature lag: Looker’s roadmap is Google’s roadmap. If a feature doesn’t align with Google’s priorities, you wait—or you pay for a custom integration

When we work with Australian startups on platform engineering and custom software development, we see this pattern repeatedly: teams choose Looker for perceived “enterprise-grade” features, then spend 18 months fighting vendor constraints.

---

Semantic Governance: LookML vs dbt + Superset {#semantic-governance}

What Semantic Governance Actually Means

Semantic governance is the practice of defining and enforcing a single source of truth for business logic. It answers questions like:

• How do we define “revenue”? (Is it gross or net? Which currencies are included?)
• Who owns the definition of a customer segment?
• How do we version and test changes to business logic?
• How do we prevent analysts from creating conflicting definitions?

Looker’s approach: centralise all business logic in LookML Explores, restrict who can create them, and enforce access controls. This works well if your organisation trusts Looker’s UI and doesn’t need to integrate logic elsewhere.

The dbt approach to semantic governance is different: define business logic in SQL (or YAML for the semantic layer), version it in Git, test it automatically, and expose it via APIs or BI tools. This works better if your organisation values code-based governance, version control, and cross-platform portability.

LookML Governance Strengths

• Centralised UI: Non-technical users can’t accidentally break the model
• Role-based access: Fine-grained control over who sees what
• Caching: Looker’s caching layer can optimise expensive queries
• Pre-built Explores: Users get guided experiences, not raw SQL

LookML Governance Weaknesses

• No version control: LookML changes aren’t tracked in Git (unless you use Looker’s API to sync)
• Limited testing: Testing LookML requires custom scripts or third-party tools
• Tight coupling: Business logic is locked inside Looker; it can’t be reused in other tools
• Skill concentration: Only Looker experts can modify the model

dbt + Semantic Layer Governance Strengths

• Git-based versioning: Every change is tracked, reviewable, and reversible
• Automated testing: dbt’s test framework catches logic errors before they reach production
• Portable logic: Your business logic is SQL (or YAML), usable across any tool
• Distributed ownership: Data engineers, analytics engineers, and analysts can all contribute
• Auditability: Full lineage and change history for compliance (important for SOC 2 and ISO 27001)

dbt + Semantic Layer Governance Weaknesses

• Steeper learning curve: Requires SQL and Git proficiency
• More moving parts: You’re managing dbt, Superset, and potentially a separate semantic layer
• Less polish: Superset’s UI isn’t as polished as Looker’s (though it’s improving)
• Caching complexity: You need to configure caching separately (via Superset or database)

For Australian enterprises pursuing SOC 2 compliance or ISO 27001 compliance via Vanta, the dbt + semantic layer approach is often easier to audit. Your business logic is in Git, with full change history. Looker’s LookML changes are harder to trace.

---

Migration Effort and Timeline {#migration-effort}

What’s Actually Involved in Moving from Looker

Migrating away from Looker isn’t just a technical problem—it’s an organisational one. Here’s what we’ve seen in practice:

Phase 1: Audit and Inventory (2–3 weeks)

• Document all LookML models, Explores, and dashboards
• Identify which are actively used vs legacy
• Map dependencies and relationships
• Estimate effort for each component

Phase 2: Rebuild Semantic Model (4–8 weeks)

• Translate LookML models to dbt models (SQL)
• Build the semantic layer (dbt semantic layer or Cube.js)
• Write tests for each dimension and measure
• Validate against production Looker queries

Phase 3: Migrate Dashboards (2–4 weeks)

• Recreate dashboards in Superset
• Rebuild filters and interactivity
• Optimise queries for Superset’s execution model

Phase 4: Cutover and Training (1–2 weeks)

• Switch users to the new platform
• Provide training and documentation
• Monitor for issues and optimise

Total migration time: 8–16 weeks for a typical mid-market organisation.

For a 100-person organisation with 50 active Looker users and 150 dashboards, expect:

• Internal effort: 400–800 hours (data engineers, analytics engineers, BI team)
• External consulting: AU$40K–80K (if you use a partner like PADISO)
• Downtime risk: 1–2 weeks of reduced analytics capability during cutover

Reducing Migration Risk

We’ve found that the organisations that migrate most successfully:

1. Run in parallel: Keep Looker running while you build the new stack
2. Migrate incrementally: Move dashboards in waves, not all at once
3. Automate validation: Write scripts to compare Looker queries against dbt/Superset queries
4. Invest in training: Your team needs to understand dbt and SQL, not just Superset’s UI

When we’ve managed AI & Agents Automation and platform engineering projects, we’ve learned that the most expensive migrations are those that try to be too clever. Moving from Looker to D23.io works best when you accept that some things will change. Your dashboards won’t look identical. Your query performance might improve or degrade. Your team will need to learn new tools.

The organisations that fail are those that try to replicate Looker’s exact behaviour in Superset. That’s not the goal. The goal is to get better governance, lower costs, and more flexibility.

---

Real-World Decision Framework {#decision-framework}

How to Evaluate Looker vs D23.io for Your Organisation

Instead of feature checklists, we recommend a decision framework based on four dimensions:

1. Lock-In Tolerance

Ask yourself: How important is portability to your business?

• High lock-in tolerance: You’re happy to be on Looker long-term, and you value its polish and ecosystem
• Medium tolerance: You want flexibility, but you’re willing to pay for it
• Low tolerance: You need portability; you can’t afford to be trapped on one vendor’s roadmap

If you have low lock-in tolerance, D23.io wins decisively. If you have high tolerance, Looker may still be the right choice.

2. Team Capability

Ask yourself: Does your team have SQL and Git expertise?

• Strong SQL/Git skills: dbt + Superset is natural; your team will be productive quickly
• Moderate skills: You’ll need training, but it’s achievable in 4–6 weeks
• Weak skills: Looker’s UI-driven approach is easier to learn, but you’ll be limited by the tool’s constraints

For Australian startups and mid-market operators, we often find that SQL and Git skills are more common than LookML expertise. This favours D23.io.

3. Cost Sensitivity

Ask yourself: Is total cost of ownership a primary driver?

• High cost sensitivity: D23.io’s lower licensing costs and reduced lock-in make it attractive
• Medium sensitivity: The 30–40% cost difference matters, but not decisively
• Low sensitivity: You’re willing to pay for Looker’s polish and support

For Australian mid-market companies (AU$10M–100M revenue), cost sensitivity is typically medium-to-high. D23.io’s cost advantage is meaningful.

4. Governance and Compliance Requirements

Ask yourself: Do you need strong audit trails and version control?

• High requirements: dbt’s Git-based approach is superior for SOC 2 and ISO 27001
• Medium requirements: Both platforms can meet your needs with the right configuration
• Low requirements: Looker’s centralised model is sufficient

For Australian enterprises pursuing security audit readiness via Vanta, the dbt + semantic layer approach is often easier to audit and document.

The Decision Matrix

Dimension	Looker Wins	D23.io Wins
Lock-in tolerance	High	Low
Team SQL/Git skills	Weak	Strong
Cost sensitivity	Low	High
Governance/compliance	Medium	High
UI polish	Yes	No (improving)
Feature maturity	High	Medium
Vendor risk	Google (low)	Distributed (very low)

If you score 3+ points in the D23.io column, migration is likely worth evaluating.

---

When to Stay with Looker {#when-looker-wins}

Looker Remains the Right Choice If…

1. You Have Strong Looker Expertise

If your team has spent 2+ years building LookML models and they’re deeply embedded in your workflows, the switching cost may outweigh the benefits. The lock-in cost is already sunk; the question is whether future benefits justify migration.

Our rule of thumb: if you’ve invested more than AU$100K in LookML development, stay with Looker unless you have a compelling reason to leave (e.g., cost pressure, compliance requirements, or a major platform shift).

2. You Require Enterprise Support and SLAs

Looker’s enterprise support is excellent. If you need 24/7 support, guaranteed SLAs, and a dedicated account team, Looker delivers. D23.io’s support is good, but it’s not enterprise-grade.

For Australian enterprises with mission-critical analytics, Looker’s support is worth paying for.

3. Your Users Demand Polish

Looker’s UI is genuinely better than Superset’s. If your organisation has hundreds of business users who expect a polished, intuitive experience, Looker is easier to deploy and support.

Superset’s UI is improving, but Looker still has the edge.

4. You’re Deeply Integrated with Google Cloud

If you’re running BigQuery, Dataflow, and other Google Cloud services, Looker’s integration is seamless. You get native caching, optimised queries, and tight integration with Google’s ecosystem.

For Australian organisations using Google Cloud as their primary data platform, Looker’s integration advantage is real.

5. You Have Limited Internal Engineering Capacity

If your data team is small (1–2 people) and you can’t afford to invest in dbt expertise, Looker’s managed approach is simpler. You’re outsourcing complexity to the vendor.

For Australian startups with lean teams, this is a valid reason to choose Looker.

---

When to Move to D23.io {#when-d23io-wins}

D23.io Becomes Attractive If…

1. You’re Hitting Looker’s Limits

Common pain points we hear from Australian organisations:

• Complex transformations: Your business logic is too complex for LookML; you need SQL
• Multi-system integration: You need analytics across Salesforce, HubSpot, Stripe, and internal databases; Looker’s connectors are limited
• Custom ML integration: You want to embed ML models in dashboards; Looker’s Python support is limited
• Real-time analytics: You need sub-second query latency; Looker’s caching is adequate, but not optimal

If you’re experiencing 2+ of these, D23.io’s flexibility is compelling.

2. Cost Is a Primary Driver

If your Looker bill is growing faster than your revenue, and you have the team capacity to manage an open-source stack, migration ROI is positive.

For Australian mid-market companies, a 30–40% reduction in BI costs (AU$30K–50K per year) justifies a AU$50K migration investment within 18 months.

3. You’re Building a Data Product

If you want to embed analytics into your product (e.g., customer-facing dashboards), Superset’s open-source nature and API-first design make it easier to customise and deploy.

Looker’s embedding capabilities are good, but they’re more expensive and less flexible.

4. You Need Portability and Vendor Independence

If you’ve been burned by vendor lock-in before, or if your board is risk-averse about single-vendor dependencies, D23.io’s distributed approach is attractive.

For Australian organisations with governance-conscious boards, this is a powerful argument.

5. Your Team Knows SQL and Wants to Own Their Analytics Stack

If your data engineers prefer building their own stack over buying managed solutions, D23.io aligns with their preferences.

We’ve found that organisations with strong engineering cultures (common in Sydney startups) prefer D23.io’s approach. It feels more like building than buying.

6. You’re Pursuing SOC 2 or ISO 27001 Compliance

If you need to demonstrate strong governance and audit trails, dbt’s Git-based approach is superior. Every change is tracked, reviewable, and reversible.

When we work with Australian operators on security audit and compliance projects, we often recommend dbt + Superset specifically because the auditability is built in.

---

Next Steps and Implementation {#next-steps}

If You’re Staying with Looker

1. Optimise your LookML: Audit your existing models for redundancy and inefficiency. You may be able to reduce your license costs by consolidating Explores
2. Invest in training: Ensure your team is using Looker effectively. Many organisations leave value on the table
3. Plan for Google Cloud: If you’re not already on BigQuery, consider it. Looker’s integration with BigQuery is where it shines
4. Negotiate aggressively: Looker’s pricing is bespoke. If your contract is coming up, push back on increases. Threaten to evaluate alternatives

If You’re Evaluating Migration

1. Run a pilot: Pick 10–20 dashboards and rebuild them in Superset + dbt. Estimate the effort and validate the approach
2. Build a business case: Calculate the three-year cost difference and the migration effort. Determine your payback period
3. Engage a partner: PADISO’s experience with D23.io implementations shows that external expertise accelerates migration and reduces risk. A AU$50K engagement can save you AU$100K+ in internal effort
4. Plan for training: Budget 4–6 weeks for your team to learn dbt and Superset. This isn’t optional; it’s the difference between success and failure
5. Communicate early: Tell your users what’s changing and why. Anxiety about new tools is the #1 reason migrations fail

If You’re Building from Scratch

1. Start with D23.io: If you don’t have existing Looker investment, D23.io is the better starting point. Lower costs, more flexibility, and better alignment with modern data engineering practices
2. Use a partner: Don’t try to build your stack alone. A consulting partner like PADISO can help you avoid common pitfalls and ship faster
3. Invest in dbt expertise: dbt is the foundation. Hire or train someone who knows it deeply. This is the most important decision you’ll make
4. Plan for scale: Design your semantic layer with growth in mind. You don’t want to rebuild it when you hit 1,000 dashboards

Specific Recommendations for Australian Organisations

For Sydney startups (seed to Series B):

Start with D23.io. You have the team capability, the cost sensitivity, and the flexibility to pivot. As you grow, you can always add Looker if you need enterprise support. When we work with founders and CEOs on fractional CTO leadership, we often recommend building the analytics stack on dbt + Superset because it aligns with modern engineering practices.

For Australian mid-market companies (Series B to IPO):

Evaluate based on the decision matrix above. If you score 3+ points in the D23.io column, migration is worth serious consideration. If you score 3+ in the Looker column, stay put and optimise. The worst outcome is being stuck in the middle, paying for Looker while wishing you had more flexibility.

For Australian enterprises (AU$100M+ revenue):

You can afford Looker, and you probably should use it—but negotiate hard on pricing and lock in a multi-year commitment with defined escalation caps. Alternatively, if you have a strong engineering organisation and you’re willing to invest in dbt expertise, D23.io’s flexibility and auditability may outweigh Looker’s polish.

Working with PADISO

If you’re evaluating this decision for your organisation, PADISO’s AI and platform engineering expertise can help you navigate the trade-offs. We’ve worked with Australian startups and mid-market operators on both sides of this decision, and we can help you:

• Audit your current Looker investment: Understand what you’re actually getting and where you’re overpaying
• Build a business case: Model the costs and benefits of migration vs staying
• Execute a pilot: Rebuild a subset of your dashboards in D23.io to validate the approach
• Manage the migration: Handle the technical and organisational complexity of switching platforms

We also work with organisations on AI Advisory Services Sydney and AI adoption strategies that often intersect with BI modernisation. If you’re thinking about embedding AI into your analytics or automating your data pipeline, we can help you design that from the start.

---

Conclusion

The Looker vs D23.io decision is ultimately about lock-in tolerance, team capability, and cost sensitivity. Looker remains a strong choice if you value enterprise support, polish, and deep Google Cloud integration. D23.io (Apache Superset + dbt + semantic layer) is the better choice if you prioritise portability, cost efficiency, and governance.

For most Australian mid-market and enterprise organisations, the lock-in costs of Looker are no longer justified by its feature advantages. The modern data stack has matured. Open-source tools are now genuinely competitive. The question is no longer “Is Looker good?” but “Is Looker’s lock-in worth what we’re paying?”

For many organisations, the answer is no.

If you’d like to explore this decision further, contact PADISO for a no-obligation evaluation. We can help you understand the true cost of your current platform and the realistic effort and timeline for migration if you decide to move.