How should a Solutions Architect decide on a cloud data warehouse for a new enterprise project?

A Solutions Architect should choose the warehouse by workload and enterprise constraints first, vendor features second.

• Define workloads: BI concurrency, batch ELT, streaming, ad hoc SQL, ML/AI, data sharing, and latency/SLA requirements.
• Assess ecosystem fit: existing cloud, object storage, ETL/orchestration, BI tools, IAM, networking, and team skills.
• Model 3-year TCO: compute, storage, ingestion, networking, governance, support, and idle capacity—not just query pricing.
• Evaluate enterprise requirements: security, RBAC, encryption, lineage, auditing, compliance, DR, regional residency, and availability.
• Consider architecture: conventional warehouse vs. lakehouse/open-table formats, especially if the same data will support engineering, BI, and AI.
• Run a representative POC: real data volumes, concurrency, incremental loads, difficult queries, security policies, failure recovery, and measured cost.
• Document lock-in and exit strategy: SQL compatibility, open storage formats, migration tooling, proprietary features, and portability.
• Make the decision traceable: produce a weighted requirements matrix and ADR explaining why the selected platform fits the project's actual constraints.

The key principle: don't ask “Which warehouse is best?” Ask “Which architecture minimizes risk and total cost for these specific workloads and constraints?”

Choosing a cloud data warehouse (CDW) for an enterprise project requires balancing technical scalability, total cost of ownership (TCO), governance, and ecosystem compatibility. As a Solutions Architect, you should approach this decision through a structured evaluation framework.

• Workload and Concurrency: Assess whether the primary use case is heavy batch ETL/ELT, high-concurrency BI dashboards, real-time streaming analytics, or data science/ML workloads. Look at how well the architecture decouples compute from storage to handle sudden spikes in query volume without degrading performance.
• Data Ecosystem and Integration: Evaluate native integrations with your existing data stack—including ingestion tools (e.g., Fivetran, Airbyte), transformation frameworks (e.g., dbt), and BI/visualization platforms (e.g., Tableau, Power BI). Check for support of open table formats like Apache Iceberg, Delta Lake, or Apache Hudi if you are building an open data lakehouse architecture.
• Total Cost of Ownership (TCO) and Pricing Model: Analyze the pricing mechanics—whether it is purely consumption-based (compute-per-second), reserved capacity, or credit-based. Factor in the cost of storage, cross-region data transfer, automatic scaling behaviors, and operational overhead required for tuning versus serverless maintenance.
• Governance, Security, and Compliance: Review enterprise-grade security features such as role-based and attribute-based access control (RBAC/ABAC), column/row-level security, data masking, and customer-managed encryption keys (CMEK). Ensure compliance certifications (SOC 2, HIPAA, GDPR) align with your industry requirements.
• Multi-Cloud and Portability Strategy: Determine if the enterprise mandates a multi-cloud posture (AWS, Azure, GCP). Assess vendor lock-in risks and how easily queries, metadata, and storage formats can be migrated or federated across different cloud providers.

If you'd like, let me know:

• Your primary cloud provider (AWS, Azure, GCP, or multi-cloud)
• The expected data volume and concurrency needs
• Whether you are leaning toward a pure data warehouse or an open table format/lakehouse approach

I can tailor a comparison of the top platforms (like Snowflake, BigQuery, Databricks, or Redshift) to your specific enterprise constraints.

A Solutions Architect should treat the cloud data warehouse as an enterprise platform decision, not simply a database selection. The right choice depends on workload, organizational constraints, operating model, and five-to-ten-year architecture—not just benchmark performance.

1. Start with the workload, not the vendors

Define the actual workloads you need to support:

• BI/reporting: dashboards, SQL analytics, semantic models, executive reporting.
• Data engineering: ELT, transformations, batch processing.
• Real-time analytics: streaming ingestion and low-latency queries.
• Data science/ML/AI: feature engineering, experimentation, model training/inference.
• Operational analytics: near-real-time data from transactional systems.
• Data sharing: internal domains, customers, partners, or external data products.
• Unstructured/semi-structured data: JSON, documents, logs, images, etc.

This distinction matters because a conventional warehouse-centric architecture and a lakehouse-oriented architecture can produce very different platform choices. For example, Databricks explicitly positions its SQL warehouse capabilities alongside data engineering, streaming, and ML on the same lakehouse platform.

2. Establish the non-negotiable constraints

Before comparing products, document constraints such as:

This prevents a common architectural mistake: choosing a technically impressive platform that conflicts with enterprise constraints.

3. Decide whether you really need a "warehouse"

The architectural decision may actually be among:

• Warehouse-centric: Snowflake, BigQuery, Redshift, etc.
• Lakehouse-centric: Databricks or similar platforms.
• Hybrid: object storage + warehouse/lakehouse + specialized serving systems.
• Cloud-native integrated stack: particularly compelling when the organization is heavily standardized on one cloud.

For example, Snowflake separates storage and compute and provides independently scalable virtual warehouses, while Databricks can put warehouse-style SQL workloads directly over lakehouse storage.

Don't force everything into one technology merely because the project is called a "data warehouse."

4. Score the important architectural dimensions

I'd use a weighted decision matrix rather than subjective vendor comparisons.

A reasonable starting point:

Then score each candidate from 1–5 and calculate:

Weighted score = Σ (criterion weight × vendor score)

The exact weights should come from the project's priorities.

5. Evaluate TCO, not the advertised query price

This is one of the most important SA responsibilities.

Model at least:

Total Cost = storage + compute + ingestion + transformation + orchestration + BI/query consumption + networking/egress + backup/DR + licenses + platform engineering labor

Run scenarios such as:

• normal weekday
• month-end reporting
• quarterly peak
• 2× data growth
• 5× concurrency
• failed/reprocessed pipelines
• development/test environments
• disaster recovery

Also examine the pricing behavior. Consumption-based systems can look inexpensive at low utilization and become expensive with poorly controlled workloads. Conversely, capacity commitments can be economical for predictable workloads but create waste when utilization is low.

For example, Snowflake documents both on-demand usage and capacity commitments, with pricing also varying by edition and region.

6. Test concurrency and workload isolation

Don't accept a vendor's generic benchmark.

Build a representative workload containing:

• simple BI queries
• complex joins
• aggregations over large fact tables
• incremental ELT
• full refresh
• concurrent dashboards
• ad-hoc analyst queries
• data-science workloads

Then test mixed workloads simultaneously.

A warehouse that is excellent for one giant query but struggles when 300 analysts, scheduled pipelines, and ML jobs compete for resources isn't necessarily an enterprise solution.

Architecturally, look for ways to isolate workloads. Snowflake, for example, uses independent virtual warehouses so compute workloads can be separated from one another.

7. Treat governance as a first-class architecture concern

Evaluate:

• RBAC/ABAC
• row-level security
• column-level security
• masking/tokenization
• data classification
• lineage
• auditing
• catalog/search
• retention
• encryption
• private connectivity
• separation of duties
• cross-account/cross-project governance

Ask a particularly important question:

Can the enterprise govern the platform centrally while allowing individual data domains to operate independently? That becomes critical as the platform scales beyond its first project.

8. Examine the surrounding ecosystem

The warehouse rarely exists alone.

Map the complete architecture:

Sources → ingestion → storage → transformation → warehouse/lakehouse → semantic layer → BI/AI → governance → monitoring

A platform that looks slightly weaker in isolation may be substantially better when it integrates naturally with your existing ecosystem.

For example, Databricks' current reference architectures explicitly show integration across ingestion, transformation, query/processing, serving, analysis, governance, and cloud storage rather than treating the SQL warehouse as an isolated component.

9. Consider lock-in deliberately

"Cloud agnostic" shouldn't automatically mean "better."

Ask:

• Are table formats proprietary?
• Can data remain in open object-storage formats?
• Can another engine query it?
• How difficult is migration?
• Are transformation jobs portable?
• Are governance policies portable?
• How much proprietary SQL are we introducing?
• What happens if pricing changes?
• What happens if the company acquires another cloud?

Snowflake, for example, supports AWS, Azure, and Google Cloud, but the selected cloud platform and region still affect deployment and potentially data-transfer economics.

The goal isn't necessarily zero lock-in. The goal is intentional lock-in where the business value justifies it.

10. Validate with a proof of concept

For an enterprise project, I'd make the final decision only after a controlled POC.

Use realistic, preferably anonymized enterprise data and measure:

• query latency
• concurrency
• throughput
• ingestion performance
• transformation performance
• cost per workload
• failure/recovery behavior
• security controls
• operational effort
• developer productivity

Most importantly, establish success criteria before running the POC.

Don't let the vendor optimize the demonstration around workloads that make its platform look best.

11. Make the decision at three levels

A strong architecture recommendation should answer three separate questions:

Technical fit

Can it do the job?

Performance, scale, reliability, security, integration.

Economic fit

Can we afford to operate it at the expected scale?

TCO, consumption characteristics, staffing, licensing, network costs.

Strategic fit

Should this be the enterprise platform?

Skills, ecosystem, governance, vendor viability, interoperability, future workloads, and organizational alignment.

A platform should ideally pass all three.

A practical shortlist

For a typical enterprise evaluation, I would usually put several architectures—not just several vendors—into the first round:

• Snowflake — strong candidate for a warehouse-first enterprise analytics platform with managed infrastructure and independent compute workloads.
• Google BigQuery — particularly worth evaluating when the organization is heavily invested in Google Cloud.
• Amazon Redshift — particularly worth evaluating in an AWS-centric architecture.
• Microsoft Fabric/Azure-oriented architecture — particularly compelling where Microsoft 365, Power BI, and Azure are dominant.
• Databricks — especially when data engineering, streaming, data science/ML, AI, and analytics need to converge around a lakehouse.

Those shouldn't be treated as universal rankings. The existing enterprise ecosystem and workload profile should determine the shortlist.

The SA's decision framework

I would summarize the process as:

Business requirements → workload characterization → architectural options → hard constraints → weighted scorecard → realistic POC → 3–5 year TCO → risk assessment → recommendation

And the final architecture decision should be something like:

"We recommend X because it best satisfies these specific workloads and enterprise constraints, at an estimated TCO of Y, while accepting these explicit trade-offs." That's much stronger than:

"We chose X because it's the fastest/most popular cloud data warehouse." The best Solutions Architect isn't trying to find the best data warehouse. They're trying to find the best-fit data platform for this enterprise's workload, economics, risk tolerance, and future architecture.

Skills, ecosystem, governance, vendor viability, interoperability, future workloads, and organizational alignment.

A platform should ideally pass all three.

A practical shortlist

For a typical enterprise evaluation, I would usually put several architectures—not just several vendors—into the first round:

Deciding on a cloud data warehouse (CDW) requires balancing architectural constraints, workload patterns, and total cost of ownership. As a Solutions Architect, you should evaluate options through a structured decision framework.

• Step 1: Analyze Workload Characteristics (OLAP vs. HTAP, concurrency, and query complexity).
• Step 2: Evaluate Data Ecosystem and Integration (ETL/ELT pipelines, streaming sources, and existing BI tools).
• Step 3: Assess Scalability and Performance Architecture (decoupled storage/compute, auto-scaling, and concurrency scaling).
• Step 4: Governance, Security, and Compliance (RBAC/ABAC, data masking, encryption keys, and regional residency).
• Step 5: Financial Modeling and Cost Structure (compute pricing models, storage costs, and predictable vs. burstable spend).

To help you narrow this down for your specific project, tell me:

• What are your primary data sources and expected data volume?
• What is your concurrency requirement (number of concurrent users/queries)?
• Do you have any strict compliance or multi-cloud requirements?

A Solutions Architect should treat a cloud data warehouse decision as an enterprise architecture decision, not a database product comparison. The right choice depends on business capabilities, operating model, data characteristics, security requirements, and long-term strategy. Modern platforms overlap heavily, but they optimize for different scenarios.

A structured approach:

1. Start with business requirements, not vendors

Define the outcomes the platform must enable:

• Analytics

• Executive dashboards

• Self-service BI

• Operational reporting

• Ad hoc exploration

• AI/ML

• Feature engineering

• Model training

• Generative AI applications

• Real-time inference data

• Data products

• Sharing data with customers or partners

• APIs and embedded analytics

• Data marketplaces

• Operational goals

• Time-to-insight targets

• Availability requirements

• Regulatory obligations

• Data retention policies

A warehouse optimized for finance dashboards may be a poor fit for an organization building ML platforms or real-time applications.

---

2. Assess the existing cloud ecosystem

Cloud alignment matters because data movement, identity, networking, and governance costs can dominate platform costs.

A multi-cloud requirement often changes the shortlist. For example, Snowflake supports AWS, Azure, and Google Cloud deployments, which can matter for organizations avoiding deep single-cloud dependency.

---

3. Classify the workload profile

Create a workload matrix:

Typical patterns:

• SQL-heavy enterprise BI - Strong candidates: Snowflake, BigQuery, Redshift, Databricks SQL
• Data engineering + ML + AI - Strong candidates: Databricks-style lakehouse architectures
• Highly variable exploratory analytics - Serverless models may be attractive
• Existing AWS analytics investment - AWS-native approaches may reduce operational friction

CloudRPS Fivetran

4. Decide on warehouse vs lakehouse strategy

The traditional distinction has blurred:

• Cloud data warehouse

• Curated relational analytics

• Strong SQL experience

• BI-focused workloads

• Lakehouse

• Combines data lake storage flexibility with warehouse-style analytics

• Better fit when the organization needs large-scale engineering, ML, and mixed data types

Ask:

• Do we need open storage formats?
• Will data scientists work directly with raw data?
• Do we need streaming and batch pipelines in one platform?
• Is avoiding vendor lock-in important?

InfoWorld

5. Evaluate architecture capabilities

A good evaluation checklist:

Storage

• Columnar storage
• Compression
• Partitioning/clustering
• Support for open formats
• Lifecycle management

Compute

• Independent scaling of compute and storage
• Workload isolation
• Auto-scaling
• Concurrency handling

Data integration

• Batch ingestion
• Streaming ingestion
• CDC support
• ETL/ELT tooling
• API connectivity

Governance

• Role-based access control
• Row/column security
• Data catalog
• Lineage
• Audit logging
• Encryption and key management

Developer experience

• SQL support
• Python/Scala support
• Notebooks
• CI/CD integration
• Infrastructure-as-code support

---

6. Build a realistic total-cost model

Do not compare only query prices.

Include:

• Compute
• Storage
• Data ingestion
• Data transfer/egress
• Backup and recovery
• Security tooling
• Monitoring
• Platform administration
• Training
• Migration effort
• Vendor support

A platform that appears cheaper can become more expensive if it requires significant engineering effort.

iTechGuides

7. Run a proof of concept (POC)

Avoid generic benchmarks. Use real enterprise scenarios:

Test:

• Representative datasets
• Real BI dashboards
• Peak user concurrency
• Large joins
• Incremental loads
• Data quality checks
• Security policies
• Failure recovery
• Cost monitoring

Measure:

• Query latency
• Pipeline duration
• Developer productivity
• Operational effort
• Monthly projected cost

---

8. Consider organizational fit

A platform succeeds when people can operate it.

Evaluate:

• Who owns the platform?
• Who writes pipelines?
• Who manages governance?
• What skills exist internally?
• How much managed service do you want?

Examples:

• A small analytics team may prefer a highly managed SQL experience.
• A data science organization may prefer a unified engineering and ML platform.
• A large regulated enterprise may prioritize governance and operational controls.

---

9. Make the decision with an architecture scorecard

A typical weighting:

Document:

• Why the platform was selected
• Alternatives considered
• Key assumptions
• Exit strategy
• Review date

---

Common platform positioning (high level)

CloudRPS FivetranThe final recommendation should be a business capability decision backed by architecture evidence, not a feature checklist. A strong Solutions Architect should be able to explain not only why the chosen platform fits, but also why the rejected alternatives do not fit this particular enterprise.

To decide on a cloud data warehouse (CDW) for a new enterprise project, a Solutions Architect must systematically align technical capabilities with long-term business strategy, existing cloud ecosystems, and cost constraints . The final selection must not only handle today's data volume but also support future analytical and AI workloads.

Architects evaluate and narrow down their choices through a framework of core architectural pillars:

1. Ecosystem Alignment & Vendor Lock-In

Evaluate how closely the CDW integrates with your existing infrastructure.

• Native Ecosystems: If the enterprise is heavily invested in a specific cloud provider (e.g., AWS, Google Cloud, Microsoft Azure), choosing that provider's native tool—like Amazon Redshift or Google BigQuery —greatly reduces integration complexity and optimizes network transfer fees.
• Cloud-Agnostic / Multi-Cloud: If the enterprise relies on a multi-cloud or hybrid strategy, platform-agnostic options like Snowflake or Databricks SQL Warehouse prevent vendor lock-in and enable uniform data access across clouds.

2. Workload Architecture & Scaling

Analyze how the warehouse handles the division of computing resources and data storage.

• Decoupled Compute & Storage: Ensure the architecture separates compute from storage (like Snowflake or BigQuery). This enables near-infinite, isolated querying capabilities so automated ETL pipelines won't degrade the performance of live executive dashboards.
• Serverless vs. Provisioned: Serverless solutions (e.g., BigQuery) elastically auto-scale to meet highly variable, ad-hoc query demands. Provisioned or capacity-based architectures (e.g., Redshift clusters) are more cost-efficient for predictable, steady, round-the-clock workloads.

3. Data Profile and Access Patterns

Examine the nature of incoming data and how your end-users will interact with it.

• Data Variety: Evaluate if your sources are strictly structured (SQL), semi-structured (JSON, Avro), or unstructured. If you have massive amounts of unstructured data, a Lakehouse architecture (like Databricks) might fit better than a traditional data warehouse.
• Data Velocity: Determine if the enterprise requires real-time streaming analytics (e.g., IoT data, financial fraud tracking) or if daily batch processing updates are sufficient.
• Concurrency Needs: Calculate how many automated applications and human data analysts will query the system simultaneously without experiencing bottlenecked queue times.

4. Pricing Models & Total Cost of Ownership (TCO)

A CDW can easily become a major cost driver if the wrong pricing model is selected.

• On-Demand (Pay-per-query): Charges based on bytes scanned. This is excellent for unpredictable usage patterns but runs the risk of runaway costs from unoptimized, heavy queries.
• Flat-Rate / Capacity-Based: Charges for dedicated virtual hardware or compute units over a fixed period. This offers budgeting predictability for large enterprises with steady analytics operations.

5. Governance, Security, and Compliance

Enterprise projects typically have strict operational boundaries.

• Compliance: Ensure the platform carries required industry certifications, such as HIPAA, GDPR , or SOC 2.
• Data Governance Features: Verify built-in support for Column-Level Security (CLS), Row-Level Security (RLS), dynamic data masking, and comprehensive end-to-end data lineage tracking.

CDW Decision Matrix

Use this brief overview to map enterprise project needs directly to market-leading CDWs:

To help me tailor a more specific recommendation, could you tell me a bit more about:

• What is your primary cloud provider (AWS, Azure, GCP, or multi-cloud)?
• What types of data are you mostly processing (structured databases or unstructured files)?
• Who are the main consumers of the data (BI tools, data scientists, or real-time APIs)?

To decide on a cloud data warehouse (CDW) for a new enterprise project, a Solutions Architect must systematically align technical capabilities with long-term business strategy, existing cloud ecosystems, and cost constraints . The final selection must not only handle today's data volume but also support future analytical and AI workloads.

Architects evaluate and narrow down their choices through a framework of core architectural pillars:

1. Ecosystem Alignment & Vendor Lock-In

Evaluate how closely the CDW integrates with your existing infrastructure.

• Native Ecosystems: If the enterprise is heavily invested in a specific cloud provider (e.g., AWS, Google Cloud, Microsoft Azure), choosing that provider's native tool—like Amazon Redshift or Google BigQuery —greatly reduces integration complexity and optimizes network transfer fees.
• Cloud-Agnostic / Multi-Cloud: If the enterprise relies on a multi-cloud or hybrid strategy, platform-agnostic options like Snowflake or Databricks SQL Warehouse prevent vendor lock-in and enable uniform data access across clouds.

2. Workload Architecture & Scaling

Analyze how the warehouse handles the division of computing resources and data storage.

• Decoupled Compute & Storage: Ensure the architecture separates compute from storage (like Snowflake or BigQuery). This enables near-infinite, isolated querying capabilities so automated ETL pipelines won't degrade the performance of live executive dashboards.
• Serverless vs. Provisioned: Serverless solutions (e.g., BigQuery) elastically auto-scale to meet highly variable, ad-hoc query demands. Provisioned or capacity-based architectures (e.g., Redshift clusters) are more cost-efficient for predictable, steady, round-the-clock workloads.

3. Data Profile and Access Patterns

Examine the nature of incoming data and how your end-users will interact with it.

• Data Variety: Evaluate if your sources are strictly structured (SQL), semi-structured (JSON, Avro), or unstructured. If you have massive amounts of unstructured data, a Lakehouse architecture (like Databricks) might fit better than a traditional data warehouse.
• Data Velocity: Determine if the enterprise requires real-time streaming analytics (e.g., IoT data, financial fraud tracking) or if daily batch processing updates are sufficient.
• Concurrency Needs: Calculate how many automated applications and human data analysts will query the system simultaneously without experiencing bottlenecked queue times.

4. Pricing Models & Total Cost of Ownership (TCO)

A CDW can easily become a major cost driver if the wrong pricing model is selected.

• On-Demand (Pay-per-query): Charges based on bytes scanned. This is excellent for unpredictable usage patterns but runs the risk of runaway costs from unoptimized, heavy queries.
• Flat-Rate / Capacity-Based: Charges for dedicated virtual hardware or compute units over a fixed period. This offers budgeting predictability for large enterprises with steady analytics operations.

5. Governance, Security, and Compliance

Enterprise projects typically have strict operational boundaries.

• Compliance: Ensure the platform carries required industry certifications, such as HIPAA, GDPR , or SOC 2.
• Data Governance Features: Verify built-in support for Column-Level Security (CLS), Row-Level Security (RLS), dynamic data masking, and comprehensive end-to-end data lineage tracking.

CDW Decision Matrix

Use this brief overview to map enterprise project needs directly to market-leading CDWs:

To help me tailor a more specific recommendation, could you tell me a bit more about:

• What is your primary cloud provider (AWS, Azure, GCP, or multi-cloud)?
• What types of data are you mostly processing (structured databases or unstructured files)?
• Who are the main consumers of the data (BI tools, data scientists, or real-time APIs)?

A Solutions Architect should treat cloud data-warehouse selection as an architecture decision, not a product beauty contest. The right platform is the one that best fits the project's workload, operating model, governance requirements, and economics over its expected life.

1. Start with requirements, not vendors

Build a short workload profile first:

• Data: current and projected volume, growth rate, structured/semi-structured/unstructured data.
• Ingestion: batch vs. streaming, source systems, CDC, ingestion frequency and latency.
• Queries: BI dashboards, ad hoc SQL, operational analytics, data science/ML, complex joins, aggregations.
• Concurrency: number of analysts, applications, dashboards, and peak simultaneous queries.
• Freshness: daily, hourly, near-real-time, or real-time.
• Performance: target query latency and SLA/SLO.
• Availability/DR: RPO, RTO, regional requirements.
• Security: encryption, private networking, SSO/RBAC, row/column security, auditing, regulatory requirements.
• Governance: catalog, lineage, data quality, retention, masking, residency.
• Operating model: how much infrastructure management the organization is willing to own.
• Commercial: budget, workload variability, expected utilization, licensing/egress costs.
• Strategic direction: existing cloud commitment, lakehouse strategy, AI/ML roadmap, and open-table-format requirements.

The most important question is often "What will the workload look like?", rather than "Which warehouse is fastest?"

2. Decide whether you actually need a warehouse

Before comparing products, establish the target architecture.

For example:

Sources → ingestion/CDC → object storage/lake → transformation → warehouse/lakehouse → semantic layer → BI/ML

A conventional warehouse is particularly compelling when the dominant workload is governed SQL analytics and BI.

A lakehouse becomes more attractive when you need the same underlying data for SQL analytics + data engineering + streaming + data science/ML, particularly when minimizing duplicated copies matters. Databricks, for example, explicitly positions its SQL/data-warehousing capabilities as running directly on a data lake.

3. Shortlist based on architectural fit

A useful initial shortlist might look like this:

These aren't absolute categories. Modern platforms overlap substantially, so the workload and surrounding ecosystem should determine the choice.

4. Weight the decision criteria

I'd create a scorecard before running a POC. For example:

Then score each candidate from 1–5 and calculate:

Weighted score = Σ(criteria weight × vendor score)

The precise weights should come from the business—not from the vendor's feature matrix.

5. Make TCO much more sophisticated than "price per TB"

This is where architecture teams frequently make mistakes.

Model at least:

TCO = storage + compute + ingestion + transformation + BI/query usage + data transfer/egress + backup/DR + tooling + operations + people

Also model three workload patterns:

1. Steady state — predictable daily utilization.
2. Bursting — occasional large workloads.
3. Growth scenario — 2–3 years of increasing data, users, and queries.

A platform with a superficially higher unit price can be cheaper if it requires substantially less administration or handles bursty workloads more efficiently.

Conversely, serverless/elastic pricing can become expensive if poorly controlled, so include budgets, workload limits, query governance, and chargeback/showback in the architecture.

6. Run a representative POC—not a benchmark demo

The POC should use representative enterprise data and queries.

Test:

• 10–20 representative queries
• small and very large tables
• complex joins
• incremental loads/CDC
• concurrent BI users
• peak workload
• cold vs. warm queries
• data refresh while users are querying
• failure/recovery scenarios
• security policies
• common ETL/ELT transformations
• actual data volumes or realistic scale factors

Measure:

P50/P95 query latency, throughput, concurrency, load time, cost/query, cost/TB processed, operational effort, and failure/recovery behavior.

Don't let a vendor-selected "TPC-style" benchmark decide the architecture.

7. Evaluate the operational model

Ask a surprisingly simple question:

"What will my team have to manage at 2 a.m.?" Compare:

• provisioning
• upgrades
• patching
• capacity management
• workload isolation
• performance tuning
• statistics/index/partition management
• scaling
• backups
• DR
• monitoring
• security administration

Managed platforms deliberately eliminate much of this burden. Snowflake, for example, handles infrastructure, upgrades, and much of the ongoing platform management; BigQuery similarly emphasizes serverless operation.

8. Treat governance and security as first-class architecture requirements

Don't leave these until after selecting the warehouse.

Verify:

• IAM/RBAC integration
• SSO
• service identities
• private connectivity
• encryption/key management
• row-level and column-level controls
• dynamic masking
• audit logs
• lineage/catalog integration
• data classification
• retention/deletion
• regulatory certifications
• cross-region replication
• separation of duties

For an enterprise project, a platform that is 10% faster but substantially harder to govern can be the worse architectural choice.

9. Explicitly assess lock-in

Ask:

• Can data remain in open formats/object storage?
• How portable are SQL and transformation logic?
• Are proprietary functions heavily used?
• Can another engine query the underlying data?
• How difficult is migration?
• Are metadata, security policies, and semantic models portable?
• What happens to costs if the organization changes cloud providers?

Don't automatically optimize for zero lock-in. Some proprietary capabilities are exactly what you're paying for. Instead, decide where lock-in is acceptable and where abstraction/open formats are strategically important.

10. Produce an Architecture Decision Record

The final decision should be defensible six months later.

A good ADR contains:

Decision: Selected platform and deployment architecture.

Context: Business requirements, workload characteristics, constraints.

Alternatives considered: At least 2–4 credible alternatives.

Decision criteria: Weighted requirements and scores.

POC evidence: Performance, concurrency, cost and operational results.

Risks: Lock-in, cost variability, skills, ecosystem dependencies, migration.

Mitigations: Open storage formats, cost controls, abstraction layers, training, DR strategy, etc.

Rejected alternatives: And, importantly, why they were rejected.

The SA's mental model

I'd boil the whole process down to this:

Requirements → workload model → target architecture → shortlist → weighted scorecard → representative POC → 3-year TCO → security/governance review → ADR And avoid the classic trap of asking "Which cloud warehouse is best?"

The better question is:

"For our workload, organization, constraints, and three-year strategy, which platform gives us the best combination of business capability, performance, governance, operational simplicity, and predictable economics?" That is the level at which a Solutions Architect should make the decision.

A Solutions Architect should treat the cloud data warehouse decision as an architecture and operating-model decision, not a product popularity contest.

The key question is:

Which platform gives this enterprise the required data capabilities, performance, governance, resilience, and economics with the least long-term architectural friction?

1. Start with workload requirements, not vendors

Before comparing products, characterize the workload.

Don't accept vague requirements such as "high performance" or "scalable." Turn them into measurable acceptance criteria—for example, 95th-percentile dashboard latency <5 seconds at 500 concurrent users.

2. Establish architectural constraints

Some decisions should be made before scoring vendors.

For example:

• A heavily AWS-centric organization may get substantial integration and operational advantages from Redshift.
• A Microsoft-centric organization with extensive Power BI usage may find Fabric particularly compelling.
• An organization wanting a relatively cloud-independent analytical platform may favor Snowflake; Snowflake supports AWS, Azure, and Google Cloud deployments.
• A GCP-centric organization with highly elastic analytical workloads may strongly consider BigQuery, whose serverless model automatically allocates compute and offers both on-demand and capacity-based pricing.
• If the architecture is fundamentally lakehouse/Spark-oriented rather than traditional warehouse-oriented, the right answer may not be a conventional warehouse at all.

These aren't automatic selections—they're starting hypotheses.

3. Evaluate the major architectural dimensions

I'd normally create a weighted scorecard like this:

Then score each candidate 1–5, with evidence for every score.

Importantly, don't let a vendor's marketing claim become the evidence. Run the workload.

4. Pay special attention to cost architecture

Warehouse pricing can be deceptively difficult to compare because platforms meter different things.

For example, BigQuery can charge based on data processed by queries or on slot capacity, while storage is separately priced.

Redshift Serverless, by contrast, meters compute in RPU-hours and storage separately, with automatic scaling; AWS also provides capacity reservations for more predictable workloads.

So don't compare:

"$X/TB/month" Instead model:

TCO = storage + compute + ingestion + transformation + BI/query consumption + networking + backup/DR + tooling + operations + migration + people

Run at least three scenarios:

1. Expected/base case
2. 2–3× growth
3. Burst/peak workload

Also model idle periods and bad queries. A platform that looks cheap at steady state can become expensive when workload behavior changes.

5. Test concurrency—not just single-query speed

A common architecture mistake is benchmarking one query.

Enterprise warehouses need to survive several workloads simultaneously:

• Executive dashboards
• Scheduled ETL
• Ad hoc analyst queries
• Data engineering transformations
• Data science workloads
• APIs/applications
• Potentially AI workloads

Test mixed concurrency and measure:

• p50/p95/p99 query latency
• throughput
• concurrency before degradation
• workload isolation
• scaling time
• cost as concurrency increases

The best warehouse isn't necessarily the one with the fastest individual query. It's the one that maintains acceptable performance while the enterprise is actually using it.

6. Evaluate the ecosystem as part of the platform

The warehouse doesn't exist by itself.

Map the surrounding architecture:

Sources → ingestion/CDC → storage → transformation → warehouse/lakehouse → semantic layer → BI/ML/apps → governance

For example, Fabric's warehouse is built on a lake foundation and integrates closely with Power BI, while supporting T-SQL and enterprise warehouse patterns.

Likewise, Redshift has particularly strong integration with AWS data services and S3, including querying data across warehouse and lake environments.

The important question is therefore not:

"Which warehouse has the best features?" It's:

"Which end-to-end architecture requires the fewest expensive or fragile integrations?"

7. Treat governance as a first-class architecture concern

For an enterprise, evaluate:

• IAM integration
• RBAC
• Row-level security
• Column-level security
• Data masking
• Encryption/key management
• Audit logs
• Data classification
• Lineage
• Retention/deletion
• Regulatory residency
• Cross-region replication
• Cross-account/project sharing
• Separation of duties

Don't leave these until implementation. If governance requires bolting on five additional products, that should materially affect the architecture score.

8. Decide how much cloud lock-in is acceptable

This deserves an explicit architectural decision.

Ask:

Is cloud portability actually a business requirement?

If yes, define what "portable" means.

There's a huge difference between:

• "We could migrate eventually."
• "Our data is stored in open formats."
• "Our SQL is portable."
• "Our pipelines can run on another cloud."
• "We can actively operate the same architecture on two clouds."

Trying to eliminate all lock-in can produce an unnecessarily complicated architecture. Sometimes deliberate AWS/Azure/GCP specialization is better than paying indefinitely for theoretical portability.

9. Run a proof of concept with real data

The POC should be designed around the riskiest architectural assumptions, not a vendor demo.

Use representative:

• Data volumes
• Data distributions
• Query patterns
• Transformation workloads
• Concurrency
• Security policies
• Data ingestion rates

I'd create perhaps 10–20 representative queries, including intentionally ugly ones.

Measure:

Performance
Cost/query
Concurrency
Scaling behavior
Ingestion throughput
Transformation throughput
Failure/recovery behavior
Developer effort
Operational effort

Then calculate something like:

Cost per 1,000 analytical queries

and

Monthly TCO at projected Year 1 / Year 3 / Year 5 volumes

That makes the decision much more defensible.

10. Consider the warehouse's role in the future architecture

A particularly important question in 2026 is whether you're selecting merely a warehouse or the enterprise's broader data/AI platform.

For example, if the organization expects:

BI + lake + streaming + ML + AI + governed sharing + application analytics

then evaluate the broader platform architecture rather than optimizing narrowly for SQL analytics.

This is also where warehouse-vs-lakehouse becomes important. Microsoft, for example, explicitly distinguishes warehouse scenarios centered on structured/semi-structured enterprise analytics from lakehouse scenarios involving heterogeneous/unstructured data and Spark-centric development.

A practical decision framework

I'd structure the architecture review as:

1. Business requirements
        ↓
2. Workload characterization
        ↓
3. Non-negotiable constraints
        ↓
4. Candidate architecture shortlist
        ↓
5. Weighted scorecard
        ↓
6. TCO model
        ↓
7. Realistic POC
        ↓
8. Security/governance review
        ↓
9. Operational-model assessment
        ↓
10. Architecture decision + ADR

And the final Architecture Decision Record should explicitly document:

• Decision
• Alternatives considered
• Requirements
• Evaluation criteria and weights
• POC results
• 5-year TCO assumptions
• Key trade-offs
• Risks
• Vendor/cloud lock-in
• Exit strategy
• Conditions that would cause the decision to be revisited

My rule of thumb

Don't ask "Which data warehouse is best?"

Ask:

"For our specific workload, cloud strategy, governance model, engineering organization, and five-year economics, which platform minimizes architectural risk while meeting our measurable requirements?" That framing usually turns a subjective vendor debate into a defensible Solutions Architecture decision.

10. Consider the warehouse's role in the future architecture

A particularly important question in 2026 is whether you're selecting merely a warehouse or the enterprise's broader data/AI platform.

For example, if the organization expects:

BI + lake + streaming + ML + AI + governed sharing + application analytics

then evaluate the broader platform architecture rather than optimizing narrowly for SQL analytics.

This is also where warehouse-vs-lakehouse becomes important. Microsoft, for example, explicitly distinguishes warehouse scenarios centered on structured/semi-structured enterprise analytics from lakehouse scenarios involving heterogeneous/unstructured data and Spark-centric development.

A practical decision framework

I'd structure the architecture review as:

Choosing a cloud data warehouse (CDW) for an enterprise project requires balancing performance, governance, cost dynamics, and ecosystem integration. As a Solutions Architect, you should evaluate options through a structured, multi-dimensional decision framework.

• Analytical Workload Patterns : Analyze whether the project leans toward heavy BI reporting, high-concurrency ad-hoc queries, data science and machine learning, or real-time streaming analytics. Some platforms excel at ultra-low latency operational analytics, while others dominate massive petabyte-scale batch aggregations.
• Cost & Pricing Model : Evaluate how the platform bills compute versus storage. Separate storage/compute decoupling allows independent scaling, but credit-based or consumption models can spiral if query optimization and auto-suspension policies aren't strictly enforced.
• Data Ecosystem & Integration : Assess native compatibility with your existing data ingestion pipelines (e.g., ETL/ELT tools like Fivetran or Airbyte), orchestration frameworks, and downstream consumption tools (BI platforms like Tableau or Power BI).
• Governance, Security, & Compliance : Verify enterprise-grade capabilities including fine-grained access control (column/row-level security), masking, data lineage, encryption at rest/in transit, and compliance certifications (SOC 2, HIPAA, GDPR).
• Multi-Cloud & Portability : Determine if the enterprise requires a multi-cloud strategy (running across AWS, Azure, and GCP) or if vendor lock-in is an acceptable trade-off for deeper native cloud service integration.
• Concurrency & Elasticity : Test how the architecture handles sudden spikes in user or application queries without degrading performance, and whether it supports instant compute scaling (e.g., virtual warehouses or auto-clustering).

If you'd like, let me know:

• What specific cloud providers or current tech stack your enterprise is using
• The expected data volume and query concurrency for the project

I can help map these requirements to specific enterprise data warehouses like Snowflake, BigQuery, or Redshift.