Your bank’s finance team needs a reconciled regulatory report. Across the business, the data science team wants raw transaction logs to build a fraud model. Both are asking for a better data platform, but buying one product won’t automatically resolve their different needs.
The data lake vs data warehouse decision starts with that tension. Leaders need to agree which answers must be consistent, which questions are still exploratory, and who’s accountable when either goes wrong.
Lake or Warehouse Starts With What Your Data Must Do
For finance, the platform must produce an agreed number that someone can explain to an auditor. For the fraud team, it must preserve detailed events that might reveal an unfamiliar pattern. Treating these as the same requirement creates frustration before implementation begins.
The short answer is straightforward: a warehouse supports governed, consistent reporting; a lake retains raw and varied data for exploration and AI. A regulated organisation may need both, connected through shared access controls and traceable transformations.
Singapore’s broader digital adoption makes this distinction relevant. The Infocomm Media Development Authority reported that 96.4% of Singapore enterprises adopted at least one of six digital areas in 2025, up from 95.1% in 2024. Those areas cover cybersecurity, cloud computing, e-payments, e-commerce, data analytics and artificial intelligence, not a specific lake-versus-warehouse adoption split.
The architectural question isn’t where you can put the data. It’s what people must be able to trust and do with it.
Both architectures store data. Their names tell you less than their intended users, preparation processes and controls.
Start a data readiness assessment by examining those requirements, not by drawing a preferred platform into an architecture diagram. Otherwise, finance may receive an exploratory dataset while data scientists receive an aggregate that’s stripped of the signals they need.
Data Lake and Data Warehouse Side by Side
The practical comparison is about data types, preparation, users and accountability, not storage capacity.
Data lake vs data warehouse at a glance
| Criterion | Data lake | Data warehouse |
|---|---|---|
| Data types | Structured, semi-structured and unstructured | Mostly structured, modelled data |
| Schema | Applied when data is read | Defined before data is loaded |
| Main users | Data engineers, data scientists, ML teams | Analysts, finance and risk teams |
| Typical workloads | Exploration, ML features, raw event and log analysis | Dashboards, KPIs, regulatory reports |
| Data state on arrival | Raw, often unchecked | Cleansed and reconciled |
| Change flexibility | Easy to add new sources | New sources need modelling work |
| Governance demand | Cataloguing and lineage needed from day one | Built into curated models, still needs named owners |
What these differences mean at work
Data types determine what you can retain conveniently. Transaction tables fit naturally into either architecture, while documents, recordings and application logs are more natural lake inputs.
Schema means the agreed structure of the data, including fields and their types. Schema-on-read lets teams interpret files for a particular analysis; schema-on-write establishes the structure of the reporting tables in advance.
The table describes conventional patterns, not hard product boundaries. Modern warehouses can accept semi-structured inputs and staging data, while curated lake tables can enforce strict structures.
Main users and workloads shape the working environment. An analyst answering a board question needs an accessible business definition; a data scientist investigating unusual behaviour needs room to inspect underlying events.
The data’s condition on arrival changes who does the preparation work and when. Putting files in storage doesn’t make them suitable for a dashboard or a model.
Flexibility needs an owner
Adding a source to a lake can be straightforward, but making it useful still requires documentation, quality checks and permission decisions. Warehouse modelling makes those choices more explicit before the source reaches established reports.
Neither pattern removes the need for stewardship. A warehouse can contain conflicting revenue definitions just as a lake can contain unidentified files.
A useful data architecture design makes these responsibilities visible alongside the technical components. Ask who approves a new source, who resolves a failed quality check, and who signs off a changed business definition.
A lake optimises for what you might need later. A warehouse optimises for what you’ve already agreed to measure.
How Data Moves Through a Lake and a Warehouse
Say a retailer wants finance reporting and more detailed analysis of customer purchases. Its point-of-sale systems generate files that need to support both jobs without becoming disconnected copies nobody can reconcile.
In the lake, those files land in object storage. Engineers organise their progression through a raw zone, a refined zone for standardisation and corrections, and a curated zone for business-ready datasets.
This layered approach is commonly called a medallion architecture. The useful part isn’t the naming convention, but the ability to distinguish a source record from a corrected record and an approved business output.
From till receipt to finance report
For the warehouse, engineers extract the sales records, transform them, and load modelled tables for products, stores, dates and transactions. Some implementations load into staging first and transform inside the warehouse. Either way, finance queries the approved reporting model rather than reconstructing weekly sales from source files.
Lake queries typically use distributed engines that process files across storage. Warehouses use storage organisation and compute tuned for analytical SQL, including joins and aggregations.
A lakehouse adds managed table formats, metadata and governance to lake storage. That narrows the architectural divide: the retailer can retain source files while exposing controlled tables for reporting and model development.
Make the connections explicit
The retailer could keep detailed receipts in the lake, publish weekly sales to the warehouse, and expose both through a shared catalogue. That catalogue helps people find datasets, but permissions and compatible query engines still need configuring.
If the business needs immediate stock alerts rather than scheduled reporting, guidance on building pipelines for real-time analytics can help teams examine ingestion and processing choices. Don’t make every dataset real-time just because the platform supports it.
For a data platform build, sketch each source’s route from arrival to consumption. Mark its landing location, transformation steps, approved output and intended users. You should be able to follow a disputed sales total back to its receipts.
Hidden Costs and Performance Trade-offs
A data lake isn’t automatically cheaper. Object storage can be economical, but the storage invoice is only part of the operating cost.
Teams also pay to process files, maintain pipelines, reconcile copies and investigate failures. A lake that looks inexpensive during a demonstration may become costly when dashboard users repeatedly scan detailed history.
Hidden cost and performance levers to measure
| Lever | What to measure | Why it bites |
|---|---|---|
| Duplicate copies | Raw and curated copies of the same data | Storage and synchronisation costs grow quietly |
| Query compute | Concurrent users and scan volume per query | Cost per query rises with heavy BI use |
| Engineering time | Pipeline failures, schema drift and quality checks | Staff time can outweigh infrastructure savings |
| Query latency | p50 and p95 on your own dashboards | Vendor benchmarks may not match your workload |
| Freshness | Time from source event to usable data | Faster ingestion can raise cost and quality risk |
| Cross-border access | Where data is stored and where it is read | Adds transfer rules and review steps |
Measure completed work, not cheap capacity
Compare the cost of delivering a usable report or dataset, including support effort. Retaining raw history may be justified for investigations, but retaining every temporary transformation indefinitely usually isn’t.
Assign retention policies to intermediate outputs. Record who uses each published dataset before paying to refresh it continuously.
Storage pressure deserves attention early. In a 2024 survey of 40 Singapore public-sector business and IT leaders, 99% reported at least a 50% increase in data-storage demand after AI implementation, according to Pure Storage’s survey announcement.
Test performance under business conditions
A vendor-produced lakehouse benchmark used a 3 TB TPC-DS dataset and 103 complex SQL queries, reporting approximately 3.5 times the performance of the Spark SQL comparison configuration. That’s evidence about a particular tested setup, not a neutral ranking of architectures.
Object storage does not automatically mean slow analytics. File organisation, execution engines, caching, and the amount of data scanned all affect the result.
Reproduce the important workloads with your own regulatory reports, customer profiles or fraud investigations. Measure p50 latency, the median response, and p95 latency, which exposes slower experiences, alongside concurrent users, freshness and cost per completed query.
Buying rule: Compare platforms while the expected users are working, not while an isolated demonstration query has the system to itself.
A warehouse remains a strong purchase for tightly modelled, high-concurrency business intelligence with predictable SQL. Don’t add operational complexity unless a real workload benefits from it.
Governance Decides More Than Features in Regulated Sectors
A finance leader’s hardest question isn’t whether the platform can run a query. It’s whether someone can explain the result, reproduce it and account for the data behind it.
In its 2024 data governance information paper, the Monetary Authority of Singapore described supervisory reviews conducted in 2022 and 2023, finding that all banks reviewed had a central data-management office or equivalent function, with responsibilities including metadata, lineage documentation and data-quality controls. This is an operating-model requirement, not something a storage engine supplies by itself.
Can someone defend the dataset?
Curated, reconciled reporting lets risk and finance teams work from an approved basis. Detailed lake data adds investigative value, but collecting more records without ownership makes it harder to establish which records are appropriate for a decision.
A 2025 study reported by CFOtech Asia, covering 200 Singapore business and analytics decision-makers, found that 91% believed their data strategies required a complete overhaul for AI, 21% of company data was estimated to be siloed, inaccessible or otherwise unusable, and 40% reported formal data-governance frameworks.
For financial institutions, MAS’s AI risk-management guidelines expect fit-for-purpose, representative data and documented sourcing, processing and lineage. Its response on AI risk-management expectations also addresses privacy and data-protection obligations when processing happens outside Singapore.
Turn policy into working responsibilities
For teams untangling departmental repositories, CloudOrbis Inc.’s guide to governing scattered business data offers a useful companion perspective. Translate policy into named approvers, access reviews and an escalation route for disputed records.
Ekipa’s Data Modernisation combines readiness assessments, platform architecture and data engineering to prepare systems for scalable AI. Its data readiness assessment is a natural first step because technology is the easier part; getting people to work differently requires deliberate attention.
Which architecture makes accountable data use auditable across analytics and AI?
The team must answer:
-
What data is used?
Identify the approved dataset and purpose.
-
Where does it reside?
Include working copies and processing locations.
-
How was it obtained?
Establish provenance and permitted use.
-
Who can access it?
Name owners and enforce access rules.
Use Cases Where Each Architecture Wins
Which architecture fits which use case
| Use case | Better fit | Why |
|---|---|---|
| Regulatory and risk reporting on fixed definitions | Warehouse, or governed hybrid | Repeatable, auditable numbers matter more than flexibility |
| Fraud and transaction analytics | Lake or lakehouse | Large volumes of granular, semi-structured events |
| Customer 360 across many systems | Hybrid | Warehouse for trusted profiles, lake for raw source feeds |
| Finance dashboards for a mid-sized firm | Warehouse | Steady SQL workloads with a small set of trusted metrics |
| Generative AI on internal documents | Lakehouse or governed lake with a curated layer | Needs unstructured data plus access control and lineage |
| Manufacturing sensor streams | Lake for raw data, warehouse for KPIs | Raw telemetry is economical to retain; plant KPIs need stable definitions |
| Ad hoc data science experiments | Lake | Teams need to explore data before fixing schemas |
A bank separates investigation from official reporting
Consider a regional bank assessing a new fraud-detection use case. Its warehouse already supports capital and liquidity reporting, with approved reconciliation and sign-off processes.
Replacing that reporting environment would introduce migration work without necessarily improving the fraud investigation. A more focused choice is to add a lake for transaction events and investigative signals, connected to approved customer and account reference data.
The governed connection matters more than the diagram. Investigators need to know which account identifier links the datasets, how late transactions are handled, and whether they’re authorised to use each attribute.
The bank can then promote useful fraud features into controlled production datasets without exposing every exploratory output to reporting users. Finance keeps its approved reporting process while the fraud team gains access to appropriate detail.
That’s a hypothetical design, not a claim that every bank should operate separate platforms. If a shared environment meets both workloads and control requirements, maintaining another system may add little value.
A public-sector implementation combines both patterns
A published GovTech customer account describes a move from on-premises analytics and visualisation infrastructure to a cloud-based lakehouse environment. The implementation used a central lake backbone, a medallion architecture, automated pipelines, fine-grained catalogue access controls and separation of storage from compute.
The reported environment supported recruitment, finance planning and procurement, alongside governance, security and collaboration. Its relevance is the combination of flexible storage with controlled consumption, not a reason to copy a particular technology stack.
For a recruitment analyst, success means finding an approved dataset with an understandable definition and appropriate permissions. For an engineer, success means changing an ingestion pipeline without unexpectedly breaking that analyst’s output.
Match the architecture to the team
Internal-document AI needs more than somewhere to keep files. The application must respect document permissions, exclude withdrawn material and preserve a route back to the source.
A small finance team has a different problem. It may gain more from agreed margin definitions and dependable refreshes than from a broad experimentation environment.
Choose for the people who’ll use and operate the system. A hybrid only works when the organisation can fund the ownership, monitoring and integration it creates.
Common Questions Before You Decide
Is a data lake cheaper than a data warehouse?
Not always. Duplicate copies, heavy concurrent queries and pipeline maintenance can remove the apparent storage saving.
Compare the cost of usable outputs, including engineering support, rather than storage capacity alone.
Can a data lake replace a warehouse for regulatory reporting?
Not as a direct swap of curated tables for raw files. Regulatory reporting needs controlled definitions, reconciliation and reproducibility.
A lakehouse can provide the reporting layer, but those controls still have to be designed and operated. The requirement is a governed output, not necessarily a separate warehouse product.
What is a lakehouse?
A lakehouse adds managed tables, metadata and governance to lake storage so that exploration and reporting can share a foundation.
It can reduce unnecessary movement between systems. It doesn’t eliminate the need to approve metrics, monitor quality or assign owners.
Do I need both a lake and a warehouse?
Only if your workloads justify both capabilities. A mixed requirement for repeatable metrics and detailed, varied source data may support a hybrid, but it doesn’t automatically justify separate platforms.
Check whether a simpler design can meet the actual consumption and control requirements before adding another operating environment.
Which should a small team start with?
A warehouse-oriented approach is usually a sensible starting point when the immediate need is governed reporting from business systems. Prioritise a lake when retaining raw data or supporting experimental AI is central to the work.
Be honest about support capacity. A design that requires specialist maintenance nobody can provide isn’t a practical starting point.
Publishing note: These visible questions and answers are candidates for FAQPage structured data. Keep any markup consistent with the published wording and check current search-engine eligibility rules before implementation.
Confirm Your Architecture Before You Buy a Platform
Bring finance, operations, risk and the data team into the same decision. Ask them to agree on evidence the pilot must produce, not just features they’d like to have.
-
List the top five decisions the data must support: Name the person making each decision and the consequence of an incorrect or late answer. “Improve analytics” isn’t specific enough; approving liquidity reporting or prioritising suspected fraud is.
-
Separate repeatable reporting from exploratory work: Mark which decisions need approved metrics and which require raw or unstructured inputs. Include freshness needs so a scheduled management report doesn’t inherit the cost of immediate processing.
-
Check governance readiness: Establish what’s used, where it resides, how it was obtained and who can access it. Assign owners and explicit rules for sensitive customer data before widening availability.
-
Choose a starting architectural pattern: Use a warehouse for governed reporting, a lake for raw and experimental work, or a hybrid or lakehouse when both are justified. Keep source acquisition separate from architecture selection; if enrichment is involved, looot’s guidance on how to choose a data enrichment tool can help clarify input requirements.
-
Run a bounded pilot with representative workloads: Measure duplicate storage, compute, engineering effort, latency, freshness and cross-border handling. Include failure recovery and ordinary users, not just the implementation team.
-
Buy only when the pilot and governance review agree: A fast result isn’t sufficient if access controls fail. A compliant design also needs to meet the business’s response-time and support requirements.
Resolve the organisational choices early
Teams rush past workload classification and ownership because product demonstrations feel more concrete. Those skipped decisions later become arguments about scope, permissions and who must fix broken outputs.
The visual route can help stakeholders start the conversation; the pilot and governance checks above provide the purchase gate.
Ekipa’s AI Use-Case Discovery Workshop helps identify and prioritise where AI is worth pursuing. Coaching and embedded delivery experts can then help teams change how they work and build the data capability, with handover so internal teams can run it themselves.
For further reading on leadership and execution, explore the business agility and transformation articles.
Ekipa offers data readiness assessments, architecture design and delivery support to connect your platform choice to reporting, AI and governance needs. Visit Ekipa to discuss an assessment or AI Use-Case Discovery Workshop, and establish where your data investment should go before committing to a platform.