What Is the Difference Between a Data Lake and a Data Warehouse?
If you've ever sat in a meeting where someone said, "just throw it in data lake" and someone else said "but the warehouse doesn't support that format" — you already know the tension this blog is about.
As businesses collect more data than ever before, one question keeps coming up — where should it actually live, and how can this be organized properly? The answer is not always obvious, because a data lake and a data warehouse aren't just two names for the same thing; they are fundamentally different approaches to data storage, built for different purposes, different users, and different kinds of work.
At the most basic level, a data warehouse is a structured, organized system designed to store processed, clean data that's ready for reporting and business intelligence. Whereas a data lake, on the other hand, stores everything — the raw, unprocessed, structured or not — in its original form until someone needs it.
It's simple: a data warehouse is a well-organized bookstore where every book is categorized and easy to find. A data lake is more like a giant storage room where everything is thrown in first, and you figure out later how to use it.
In this guide, we'll break down exactly what the data lake vs data warehouse differences are, where they differ in architecture, cost, performance, and governance, to help you figure out which one — or which combination — fits your situation.
What Is a Data Lake?
A data lake is a centralized storage system that holds massive amounts of raw data in its native format until it is needed. And when we say raw, we mean it — structured spreadsheets, semi-structured JSON files, unstructured text documents, images, audio, video logs — all of it goes in, as-is, without being cleaned or organized upfront.
The term was coined by James Dixon back in 2010, and the metaphor still holds up: if a data warehouse is like a bottle of purified water — clean, processed, ready to drink — a data lake is the actual lake. Everything flows into it naturally. You decide what to do with it when you're ready to use it.
This approach became popular as companies started dealing with big data storage challenges that traditional systems simply weren't built for. When your data volumes hit petabyte scale and your sources include everything from IoT sensors to social media feeds, you can't afford to clean and structure everything before storing it. You need somewhere to put it all, first.
Key Features of a Data Lake
A few things make a data lake distinctly different from other storage systems — and once you understand these, everything else about how it works starts to click.
Stores All Data Types
Structured tables, semi-structured JSON or XML files, unstructured text, images, video, audio logs — everything is welcome. You don't need to decide how the data will be used before it comes in.
Schema-on-Read
It applies structure only when you read the data, not when you store it. The data sits in its raw form until a query or a process asks something of it — only then does structure get applied.
Flat Object Storage
Most modern data lakes run on platforms like, Azure Data Lake Storage Gen2, or Google Cloud Storage — keeping cost per GB remarkably low.
ELT Over ETL
Data lakes follow Extract, Load, Transform. Data lands in the lake first, and transformation happens later when there's an actual use case for it — the opposite of how a warehouse works.
Supports Multiple Workloads
Batch processing, real-time data processing, SQL analytics, and full machine learning pipelines can all run on the same underlying storage layer — a genuinely versatile foundation.
Open Format, No Vendor Lock-In
Because data lakes use open formats like Apache Parquet and ORC, you're not tied to any single vendor's ecosystem. Your data stays yours.
Data Lake Architecture Explained
You might feel a data lake is one big storage bucket from the outside, but on the inside it's organized into distinct layers — each with a specific job. Here's how it flows from start to finish.
Ingestion Layer
Data comes in from all kinds of sources — relational databases, APIs, IoT devices, application logs, streaming platforms, third-party tools. It all flows in here in its original, untouched form. The goal is simply to get the data in quickly and cheaply — nothing gets filtered or transformed at this stage.
Raw Storage Layer
Once ingested, data lands here first. Think of it as the holding zone. Everything sits in its native format — CSV, JSON, Parquet, images, whatever it came in as. This is where the cost advantage of object storage really shows up, because you're not running expensive compute just to keep data sitting still.
Processing Layer
When someone needs the data, tools like, Databricks, or AWS Glue come in to clean, transform, and prepare it for use. This is where the ELT process plays out — transformation happens here, on demand, rather than before storage.
Consumption Layer
Processed data surfaces here for whoever needs it — data scientists pulling datasets for model training, analysts running queries, or automated data pipelines feeding downstream systems and applications.
Metadata and Cataloguing Layer
Often overlooked but critically important. As your lake grows, you need a way to track what data exists, where it came from, what it means, and who can access it. Tools like AWS Glue Data Catalog, Apache Atlas, or Databricks Unity Catalog sit here — without this layer, even a well-structured lake starts sliding toward becoming a data swamp.
Advantages and Limitations of Data Lakes
Data lakes come with some genuinely compelling strengths — especially for organizations dealing with large, diverse, and fast-moving data. But they aren't without real trade-offs either.
- Handles every data type — structured, semi-structured, unstructured
- Cost-effective storage at petabyte scale
- Built for machine learning and AI workloads
- Future-proof — store data before knowing its use
- No vendor lock-in with open formats
- Supports real-time and batch processing simultaneously
- Risk of becoming a "data swamp" without governance
- Weak data quality management by default
- High technical barrier — not self-service
- Slower query performance on raw data
- Poor out-of-box BI reporting integration
- Metadata management becomes complex at scale
What Is a Data Warehouse?
A data warehouse is a centralized system built to store structured, processed data that's ready for analysis the moment someone needs it. Unlike a data lake where raw data flows in and gets figured out later, a warehouse takes the opposite approach — everything is cleaned, organized, and structured before it ever gets stored. The result is a system that's fast, reliable, and purpose-built for business intelligence and enterprise reporting.
Key Features of a Data Warehouse
A data warehouse has a very distinct set of characteristics that separate it from other storage systems. Once you see how it's designed, it becomes clear exactly what it's optimized for — and why.
Stores Only Structured Data
A data warehouse works exclusively with structured data — rows, columns, clearly defined fields. Every piece of data has a known format and a defined place before it's allowed in.
Schema-on-Write
Before data enters a warehouse, it must conform to a predefined schema. Structure is decided upfront at the point of storage — not at the point of querying. This is what makes warehouses query-ready at all times.
ETL Process
Data warehouses follow Extract, Transform, Load. Data gets cleaned and transformed before it ever lands in the warehouse — ensuring what's inside is always reliable and ready to use.
Optimized for OLAP Workloads
Warehouses are built around OLAP systems — specifically designed for complex analytical queries that scan large amounts of historical data and aggregate numbers for decision-making.
Subject-Oriented and Time-Variant
Data is organized around business subjects — sales, finance, customers, products — rather than individual applications. It retains historical data over time, invaluable for trend analysis.
Direct Integration with BI Tools
Connects cleanly with business intelligence tools like Tableau, Power BI, and Looker. Because data is already structured, analysts can plug in and start building reports immediately.
Data Warehouse Architecture Explained
Understanding how a data warehouse is built helps explain why it performs the way it does. It's not just a database — it's a layered system designed specifically around how businesses consume data.
Bottom Tier — Database Server
The foundation of the warehouse. Actual data sits here, stored in a relational database optimized for analytical queries. On-premises options include traditional systems like Teradata and SQL Server. Modern cloud data warehouse platforms like Snowflake, Google BigQuery, and Amazon Redshift operate at this layer, with the added benefits of elastic scaling and managed infrastructure.
Middle Tier — OLAP Engine
This layer sits between the raw data and the end user. The OLAP engine processes queries, handles aggregations, and applies the data modeling logic that turns raw stored data into meaningful business metrics — making complex multi-dimensional analysis fast and reliable.
Top Tier — Front-End and BI Layer
This is what most people in the business actually see. Dashboards, reports, and self-service analytics tools all live here. Because the layers beneath have done the heavy lifting, users at this tier can query and explore with speed and confidence.
Advantages and Limitations of Data Warehouses
For certain types of organizations and certain types of work, a data warehouse is hard to beat. But it's not the right tool for every situation — there are real constraints that matter, especially as data needs evolve.
- Fast, reliable query performance out of the box
- High data quality enforced at ingestion via ETL
- Built-in governance, access control, and audit logging
- Seamless BI reporting and dashboard integration
- Compliance-ready architecture for regulated industries
- Consistent, predictable performance for concurrent users
- Cannot handle unstructured data — a hard architectural wall
- High cost at scale — compute and storage are tightly coupled
- Rigid schema slows agility when requirements change
- Not built for machine learning or AI workloads
- Potential vendor lock-in with proprietary formats
Data Lake vs Data Warehouse: Side-by-Side Comparison
At this point, you have a solid understanding of what each system is and how it works on its own. Now let's put them next to each other — because the real clarity comes not from understanding them separately, but from seeing exactly where they diverge and why those differences matter for real decisions.
Comparison Table: Storage, Cost, Performance, Schema, and Users
Sometimes the clearest way to see the difference is to just lay it all out in one place. Here are the differences across the dimensions that matter most.
| Dimension | Data Lake | Data Warehouse |
|---|---|---|
| Data types supported | Structured, semi-structured, unstructured | Structured only |
| Schema approach | Schema-on-read | Schema-on-write |
| Processing method | ELT (Extract, Load, Transform) | ETL (Extract, Transform, Load) |
| Storage cost | Low — object storage (~$0.023/GB on S3) | Higher — compute and storage bundled |
| Query performance | Slower on raw data without tuning | Fast, consistent, optimized for analytics |
| Primary users | Data scientists, data engineers | Business analysts, BI teams |
| Scalability | Scales easily to petabytes | Scales well but at higher cost |
| Data governance | Requires deliberate layering | Built-in, mature governance features |
| Best for | ML, AI, raw data exploration, streaming | BI reporting, dashboards, compliance |
| Examples | AWS S3 + Databricks, Azure Data Lake | Snowflake, BigQuery, Amazon Redshift |
Schema-on-Read vs Schema-on-Write Explained
Wondering what schema-on-write and schema-on-read actually mean? This distinction is arguably the single biggest architectural difference between the two systems — and once you get it, everything else starts to make sense.
Schema-on-Write
The structure of the data is defined before it gets stored. When data enters a warehouse, it must already conform to a predefined schema — the right columns, the right data types, the right format. This is what makes warehouses so consistent and query-ready at all times.
Schema-on-Read
Data enters the lake in its raw, native format — no structure required. The schema is only applied at the moment someone actually queries the data. The same raw file could be interpreted differently depending on what question is being asked of it.
Which One Is Better?
Neither — they're designed for different realities. Schema-on-write is better when consistency, speed, and reliability matter more than flexibility. Schema-on-read is better when dealing with diverse data types, unknown future use cases, or environments where data scientists need raw access. In a modern data stack, you'll often find both approaches working in parallel.
Data Lake vs Data Warehouse Architecture Comparison
Understanding what each system does is one thing — seeing how they're built, layer by layer, is where the real differences become clear. The architecture of a data lake and a data warehouse isn't just different in degree; they're different in philosophy.
| Architecture Layer | Data Lake | Data Warehouse |
|---|---|---|
| Storage type | Flat object storage (AWS S3, Azure Data Lake Storage Gen2, Google Cloud Storage) | Relational database optimized for analytical queries |
| Data input | Raw, unprocessed data in native format | Pre-processed, structured data via ETL pipeline |
| First layer | Raw zone — data lands untouched in original format | Bottom tier — database server storing structured data |
| Middle layer | Processing zone — transformation on demand via Apache Spark or Databricks | OLAP engine — handles aggregations, multidimensional queries, and business logic |
| Top layer | Consumption layer — feeds ML pipelines, analytics tools, downstream warehouses | Front-end BI layer — dashboards, reports, self-service analytics tools |
| Compute model | Decoupled — storage and compute scale independently | Coupled or semi-coupled depending on platform |
| Data format | Open formats — Parquet, ORC, JSON, CSV, images, logs | Proprietary or structured formats — rows and columns |
| Scalability approach | Horizontal scaling via distributed storage | Vertical and horizontal scaling at higher cost |
| Governance layer | Optional — requires tools like AWS Glue, Apache Atlas, Unity Catalog | Built-in — native access controls, audit logging, schema enforcement |
| Modern platforms | Databricks, AWS Lake Formation, Azure Data Lake, Google BigLake | Snowflake, Amazon Redshift, Google BigQuery, Azure Synapse Analytics |
The pattern here is clear — a data lake defers decisions and optimizes for ingestion speed and flexibility, while a data warehouse enforces decisions upfront and optimizes for query reliability and speed. In most modern enterprise data architecture setups, both layers coexist — raw data lands in the lake, and the most business-critical structured data gets promoted into the warehouse.
Cost Comparison: Storage, Processing, and Maintenance
Cost is one of the most common decision factors when choosing between a data lake and a data warehouse — and also one of the most misunderstood. The answer is rarely as simple as "one is cheaper than the other." Here's how the two systems compare across three cost dimensions, with a clear verdict on each.
Object storage like AWS S3 costs around $0.023 per GB. Storing a terabyte costs roughly $23 a month — with no preprocessing required.
Estimated annual cost of running an in-house warehouse with 1TB storage and 100,000 queries per month — including engineering overhead, compute, and licensing. (Fivetran/GigaOm)
Cheaper for data ingestion compared to leading data warehouses, according to a benchmark by Fivetran and GigaOm. On raw ingestion alone, the gap is significant.
Every new data source requires a transformation pipeline to be built upfront before anything gets stored — adding significant engineering and compute cost at the ingestion stage.
Every time you query raw data in a lake, you're paying compute to apply structure on the fly. For repeated BI queries running dozens of times a day, those costs add up fast.
Once data is in, queries are fast, efficient, and cheap to run repeatedly. For high-frequency, predictable reporting workloads, this model is very cost-efficient per query.
Lower upfront maintenance, but without proper governance tooling, data quality problems pile up quietly and become expensive to fix retroactively. The hidden cost is real.
Requires significant upfront investment — complex setup, schema maintenance, ETL pipeline updates, and version management all need dedicated engineering time. Predictable, but not cheap.
The Overall Cost Reality
Data lakes are highly scalable and more affordable for storing large volumes of raw data. Warehouses cost more but deliver more predictable per-insight value for structured, repeated queries. Many teams use a lake for storage and a warehouse for analytics to balance scale and speed — and that combined approach often delivers the best total cost of ownership.
Performance and Scalability Differences
Performance is where the data warehouse has traditionally held its ground — and where the data lake has taken criticism. But the gap has narrowed significantly with modern tooling. Here's a straight scorecard across seven dimensions.
| Dimension | Data Lake | Data Warehouse | Winner |
|---|---|---|---|
| Structured query speed | Slower — structure applied at query time adds overhead | Fast and consistent — pre-indexed, pre-processed data answers queries in seconds | Warehouse |
| Unstructured data queries | Handles it natively — built for diverse formats | Cannot handle unstructured data at all | Lake |
| Concurrent user workloads | Not optimized out of the box — high concurrency creates contention | Built for it — Snowflake and BigQuery handle multi-cluster concurrency natively | Warehouse |
| Scalability at petabyte level | Highly scalable — no need to adhere to a fixed schema; scales to any volume | Scales well on cloud platforms but at increasing cost as volume grows | Lake |
| Real-time streaming workloads | Strong — decoupled compute and storage supports high-velocity pipelines via Apache Kafka | Improving but traditionally weaker — built primarily for batch analytics | Lake |
| ML and AI workloads | Purpose-built — raw, unfiltered data is exactly what model training requires | Poor fit — aggregated, structured data bottlenecks ML pipelines | Lake |
| BI dashboards and reporting | Requires additional transformation layers before connecting to most BI tools | Designed for the fastest query performance — dashboards run in seconds from a well-designed warehouse | Warehouse |
Overall Verdict
Warehouse wins where consistency and speed matter — structured analytics, BI reporting, and concurrent users. Lake wins where scale, flexibility, and workload diversity matter — ML, streaming, petabyte storage, and unstructured data. Which rounds matter most depends entirely on what your team actually does with data day to day.
Security, Governance, and Compliance
For many organizations — especially those in regulated industries — security and governance aren't just features to consider. They're requirements that can make or break an architectural decision. Let's clear up some common myths.
Reality: Data warehouses come with robust security, user access controls, and governance frameworks out of the box — decades of development have gone into protecting warehouse data and ensuring privacy and compliance. But built-in doesn't mean automatic. Role definitions, data classification, retention policies, and access permissions all still need deliberate configuration. Assuming the warehouse handles it without setup is how compliance gaps quietly appear.
Reality: Data lakes, built on newer big data technologies, historically have weaker native security controls. The sheer breadth of data in a lake — potentially everything from HR records to IoT sensor feeds — can make it harder to govern. But "harder" doesn't mean impossible. Modern platforms like AWS Lake Formation, Databricks Unity Catalog, and Azure Purview have significantly closed the gap. The risk isn't the technology — it's the teams that treat governance as an afterthought.
Reality: Regulated industries like finance and healthcare can and do run data lakes successfully. If your industry demands strict compliance and you need fine-grained control over who sees what, a data warehouse provides a more straightforward path to achieving this. A lake requires more deliberate governance tooling to reach the same compliance standard — but it can be done with the right engineering discipline.
Reality: About 54% of executives have made data governance a top priority for 2024–2025, but many implementations treat governance as a one-time project rather than an ongoing practice. Regulations change. Data sources change. Teams change. Governance is a continuous process — not a checkbox — in both systems.
Reality: A warehouse can't become a data swamp in the traditional sense because its schema-on-write model enforces structure at entry. But warehouses have their own version — siloed data marts, outdated schemas, undocumented transformations, and stale reports nobody trusts anymore. The symptoms are different, but the root cause — lack of governance discipline — is exactly the same.
The Governance Bottom Line
Data warehouses are easier to govern due to their structured nature, allowing organizations to apply access controls and monitor data usage more efficiently. Data lakes are more challenging to govern due to the unstructured nature of the data — proper governance tools are required to track and manage data access. Neither system governs itself. The question is whether your team has the tooling, discipline, and ownership culture to govern whichever system you choose.
"Without data, you're just another person with an opinion. The architecture you choose determines whether that data actually becomes insight — or just expensive noise sitting in storage."— W. Edwards Deming, Data Quality Pioneer (adapted for the modern data stack)
Data Lake vs Data Warehouse vs Data Lakehouse
The conversation around data storage didn't start with three options. It started with one, evolved into two, and the tension between those two eventually created a third. Here's how that happened — and where things stand now.
The Evolution
Data warehouses were the standard — structured, governed, fast. Built for a world where most business data was transactional and the primary consumer was the BI analyst. It worked well until data started coming in formats and volumes that warehouses simply weren't designed for.
The explosion of big data, IoT, social media, and machine learning created a new problem — organizations needed somewhere to store everything: raw, fast, and cheap. Data lakes emerged as a new big-data storage architecture enabling a single repository for all data. But flexibility came at a cost — governance, reliability, and query performance all suffered without significant engineering effort.
The lakehouse emerged to combine the best of both worlds — the scalability and flexibility of data lakes with the structure, performance, and governance of data warehouses. Open table formats like Delta Lake, Apache Iceberg, and Apache Hudi made it technically possible. Platforms like Databricks, Snowflake, and Microsoft Fabric made it commercially accessible.
The Three-Way Comparison
| Dimension | Data Warehouse | Data Lake | Data Lakehouse |
|---|---|---|---|
| Data types | Structured only | All types | All types |
| Schema | Schema-on-write | Schema-on-read | Both — flexible enforcement |
| Storage cost | High | Low | Low — cloud object storage |
| Query performance | Fast | Slower without tuning | Fast — warehouse-grade on lake storage |
| ACID transactions | Yes | No | Yes — via Delta Lake / Iceberg |
| Governance | Built-in, mature | Requires deliberate tooling | Built-in, unified |
| BI support | Native | Requires additional layers | Native |
| ML/AI support | Poor | Excellent | Excellent |
| Real-time streaming | Limited | Strong | Strong |
| Primary users | Business analysts, BI teams | Data scientists, engineers | All — BI, data science, AI, ML |
| Best for | Structured analytics, compliance | Raw storage, exploration, ML pipelines | Unified analytics across all workloads |
| Popular platforms | Snowflake, BigQuery, Redshift | AWS S3 + Databricks, Azure Data Lake | Databricks Lakehouse, Microsoft Fabric, Snowflake |
Lakehouse vs Data Lake vs Data Warehouse: When Each Makes Sense
The honest answer is that most mature organizations in 2026 aren't choosing just one. Many enterprise data architectures use two or all three in a holistic data fabric — an organization can use a data lake as a general-purpose storage solution for all incoming data in any format, data from the lake can be fed to data warehouses tailored to individual business units, and a data lakehouse can help data scientists and data engineers more easily work with raw data for machine learning, AI, and data science projects.
The warehouse is not going away — it remains the gold standard for governed, structured, compliance-driven analytics. The lake is not going away — it remains the most cost-effective raw storage layer at scale. But the lakehouse is fast becoming the default starting point for organizations building a modern data architecture from scratch.
Common Mistakes to Avoid
Even the best data teams make avoidable mistakes when building or choosing between these architectures. Here's a straight checklist — go through it before you commit to anything.
- Nobody can tell you with confidence what data exists in your lake
- Your warehouse schema hasn't been updated in over a year, but your business has changed significantly
- Data scientists are duplicating data from the warehouse into their own local environments
- Your "data lake" is being used as a dumping ground with no transformation ever happening
- Governance conversations keep getting pushed to "phase two" — and phase two never comes
- Your BI team and data science team are working from different versions of the same metric
- You're paying for petabytes of lake storage but only 10% of it has ever been queried
How did your checklist go?
If you ticked everything confidently, you're in good shape. If a few boxes stayed unchecked — those are exactly the gaps that quietly grow into expensive problems. Let's close them before they cost you.
Talk to an Algoscale Data Architect →Real-World Use Cases and Examples
The best way to understand which architecture fits is to see it in action. Here's how real organizations across different industries are using each one.
Data Warehouse Use Cases in Finance and Compliance
Finance runs on trust — trust in numbers, trust in reports, trust in the data behind every decision. That's why the data warehouse has always been the natural home for financial data.
Banks and financial institutions use warehouses to generate accurate, auditable reports for regulators like the SEC, FCA, and Basel III compliance bodies. The structured, governed nature of a warehouse makes it straightforward to prove data lineage and accuracy.
Real-time BI dashboards built on warehouse data help fraud analysts spot anomalies in transaction patterns across millions of records — fast.
CFO teams pull historical structured data from warehouses to model revenue projections, budget variances, and scenario planning — all through standard BI tools like Tableau or Power BI.
Data Lake Use Cases in Healthcare and IoT
Healthcare generates some of the most diverse data in any industry — and diversity is exactly what a data lake is built for.
MRI scans, X-rays, CT images — none of this belongs in a structured warehouse. Data lakes store these at scale, making them accessible to AI diagnostic models without expensive preprocessing.
Fitness trackers, patient monitors, and connected hospital equipment generate continuous streams of sensor data. A lake ingests all of it in real time without needing a predefined schema.
Genomic datasets are massive, complex, and unstructured. Research institutions use data lakes to store raw sequencing data and run machine learning models across it to identify patterns and disease markers.
How Streaming Platforms Use the Lakehouse Model
Streaming platforms sit at an interesting intersection — they need the scale and flexibility of a lake for behavioral data, and the speed and reliability of a warehouse for business reporting. The lakehouse is a natural fit.
Every time a user gets a "you might also like" suggestion, that's a machine learning model trained on petabytes of raw behavioral data stored in a lake. Netflix, Spotify, and similar platforms process billions of events daily to keep those recommendations relevant.
Business teams need clean, fast dashboards showing which content is performing, subscriber growth metrics, and churn rates. That comes from the warehouse layer of the lakehouse — same platform, different consumption layer.
Streaming platforms with ad-supported tiers use lakehouse architectures to combine raw user behavior data with structured campaign data — powering personalization at scale while keeping BI teams self-sufficient.
"The goal is to turn data into information, and information into insight. The architecture you choose is the infrastructure that either enables or prevents that transformation at scale."— Carly Fiorina, Former CEO of Hewlett-Packard
Frequently Asked Questions
Conclusion: Which One Is Right for Your Business?
No universal answer — and anyone telling you there is probably hasn't worked with both systems at scale.
A data warehouse is the right choice when your team needs fast, reliable, governed access to structured data for reporting and compliance. A data lake is the right choice when you're dealing with diverse data types, large volumes, and workloads that need raw, flexible access — like machine learning and real-time pipelines. And a data lakehouse is increasingly the right choice when you need both, on a single platform, without duplicating your data or your infrastructure.
What matters most isn't the technology — it's the fit between the architecture and the actual problems your team is trying to solve. The wrong choice isn't always picking the wrong system. It's picking the right system and implementing it without governance, without clear ownership, and without a long-term plan.
If you've read this far, you probably have a specific decision in front of you — or a specific pain point with the architecture you're already running. Either way, getting it right the first time is significantly cheaper than fixing it later.
That's Where Algoscale Comes In
We've helped organizations across finance, healthcare, retail, and technology design and implement data architectures that work in practice — not just on a whiteboard. Whether you're evaluating your first data warehouse, untangling a data swamp, or moving toward a modern lakehouse setup, our team brings the technical depth and real-world experience to get you there without the costly detours.
