Top 30 Cloud Data Warehousing & Lakehouse Platforms 2027

This report forms part of The Economy Rankings’ Artificial Intelligence & Data portfolio. Technology Ranking 2027 | Artificial Intelligence & Data | Cloud Data Warehousing & Lakehouse Platforms

An analytical platform has to do more than return one impressive query result. It must organize data, execution and permissions well enough for recurring reporting, exploration and application workloads to coexist. The operational challenge becomes clearer when those activities compete for resources or when an apparently simple query crosses several governed data environments.

Cloud Data Warehousing & Lakehouse Platforms compares 30 named analytical products and operated services. The scope includes managed warehouses, lakehouse query environments and supported cloud analytical database deployments. Generic storage and standalone visualization tools fall outside it. Different architectures remain comparable through their analytical function, while their deployment responsibilities are kept explicit.

The 2027 edition reflects research completed in October 2026. It assesses documented capabilities and inspectable operating workflows rather than claiming a common laboratory benchmark. A vendor-selected speed comparison, customer logo or contractual availability commitment does not establish independently measured superiority across this diverse group.

Tier I identifies the strongest overall results against the weighted editorial framework. Tier II and Tier III retain substantial eligible platforms with different strengths and operating emphases. Only the leading five are numbered; alphabetical presentation in the other bands avoids suggesting precision beyond the assessment.

Market Overview

The warehouse and lakehouse markets increasingly overlap. SQL services query open tables, database vendors add external-data access and managed query engines bring federation into analytical workflows. Buyers should ask which data is copied, cached, indexed or queried in place, because the word lakehouse alone does not explain execution or maintenance.

Compute organization creates another important difference. Virtual warehouses, slots, subclusters, service classes and managed query engines express different resource models. Their usefulness depends on workload shape and administrative policy. A system optimized for interactive application analytics can present a different operating trade-off from one designed around large scheduled transformations.

Governance must follow the actual access path. Catalog permissions, SQL endpoint policies and direct storage access can enforce different boundaries. Shared data does not guarantee shared authorization semantics. An architectural review should trace sensitive information through source systems, analytical storage, query execution and downstream consumers.

Consumption is equally architectural. Compute, retained data, transfer and managed features may be metered separately. Suspension and autoscaling can be helpful controls, but neither determines the complete bill without workload context. This ranking rewards understandable operating dimensions and documented limits, not a claim that one platform is universally cheaper.

Current identity also matters. Rebrands and acquisitions can change the provider while a technical product continues. The profiles identify the maintained offering and current operator, with fact boxes scoped to provider origins or a clearly labeled office. Product continuity is assessed separately from a corporate announcement.

Industry Trend — 2027

The following developments frame analytical platform selection for 2027. They are procurement and engineering considerations supported by current product provision, rather than predictions of measured future outcomes.

2027 market development	Current evidence and direction	Implication for the sector
Open analytical tables	Iceberg and related lakehouse workflows increasingly sit alongside warehouse-native storage.	Inspect catalog ownership, update semantics and optimization responsibilities before assuming portability.
Separated execution resources	Warehouses, engines and subclusters make workload isolation more configurable.	Test mixed workloads and policy changes, including the administrative work needed to maintain isolation.
Operational evidence as data	Query histories, workload tables and billing records support investigation through familiar tools.	Confirm retention, enablement and regional scope; available telemetry is not necessarily collected by default.
More application-facing analytics	Real-time engines and SQL APIs connect analytical storage with software features.	Evaluate endpoint stability, ingestion freshness and concurrent demand alongside ad hoc query performance.
Governance across access paths	Shared storage and federated analysis create multiple routes to the same information.	Check equivalent permissions through every intended SQL, catalog and direct-data route.
Agents around analytical systems	Natural-language and agent interfaces increasingly accompany warehouses.	Separate preview interfaces from established execution, authorization and operational controls.

These developments increase the value of a workload-specific pilot. A credible comparison includes administration, access changes and recovery investigation alongside representative analytical queries.

Methodology — Core Eligibility Criteria

The ranking uses an evidence-based editorial assessment tailored to this technical market. Candidates were required to satisfy the following core conditions:

• The entry must be a current named analytical platform, maintained cloud service or explicitly supported cloud analytical database deployment.
• Analytical storage or query execution must be part of the actual offering; generic object storage and standalone dashboards do not qualify.
• Cloud scope requires documented deployment or service provision, rather than an assumption that any software can run on a virtual machine.
• The current provider and material acquisition or rebrand must be identified. Absorbed products are not counted again under former owners.
• First-party technical or product evidence must establish functional provision and the relevant operating arrangement.
• Provider origins and headquarters or accurately scoped office information must be distinguishable from product launch and project history.
• Capabilities must be labeled by version, deployment and launch stage where those distinctions affect the evaluated workflow.
• Eligibility, scoring and tie decisions are editorial and independent of licensing, promotion or recognition purchases.

Methodology — Ranking Factors

• Analytical architecture and workload fitness — 30%: SQL and analytical engine depth, storage and compute organization, transaction or lakehouse semantics, and fit for the documented workloads. Architectural differences are assessed directly rather than collapsed into one unsupported speed claim.
• Evaluation and production evidence — 25%: Inspectable architecture, query diagnostics and operating workflows. Attributable deployments or disclosed tests add context where available; editorial capability assessment does not imply that we performed a common independent benchmark.
• Governance and operational resilience — 20%: Access boundaries, audit, workload isolation, catalog controls and recoverable operating information. Configuration and service responsibilities matter alongside the availability of individual features.
• Data openness and operational scale — 15%: Supported formats, catalogs, ingestion, federation, interfaces and resource management. Integration is judged through maintained workflows rather than connector counts alone.
• Transparency and cost intelligibility — 10%: Clear documentation of operating limits, resource dimensions, supported configurations and consumption. The criterion assesses intelligibility, not universally low prices or commercial attractiveness.

The five criteria carry weights of 30%, 25%, 20%, 15% and 10%, respectively. The private research record documents criterion-level editorial assessments and supporting sources. These are judgments about the documented offering, not scores from laboratory tests performed by The Economy Rankings. Missing material evidence is pursued before selection rather than silently treated as average performance. Licensing, sponsorship and likelihood of purchasing recognition do not influence eligibility, scores or tier placement.

Company Profiles and Further Reference

Names appearing in this ranking are linked to their corresponding organizational profiles in The Economy Wiki, where available. These profiles provide further background on principal activities, technology capabilities, product and service portfolios, market positioning and related rankings and analysis across The Economy Network.

Where an entry identifies a product or service line, its provider or operator is identified so that the scope of the organizational profile is clear. The Economy Wiki profiles are maintained as editorial reference pages and may be updated as new public information becomes available.

---

Tier I — Leading Cloud Data Warehousing & Lakehouse Platforms

1. Databricks

• Provider / operator: Databricks
• Headquarters: San Francisco, California, United States
• Provider origins: 2013

Databricks combines SQL warehousing with a lakehouse environment in which analytical assets can participate in wider engineering and machine-learning workflows. Different SQL warehouse arrangements provide choices about provisioning and operation. The relevant advantage is architectural breadth around shared data and catalog controls, rather than an assertion that every workload benefits equally from one engine or deployment mode.

Its documentation makes operations unusually inspectable. Query history, warehouse events, configuration history and lineage appear in system tables with stated scope and retention. Unity Catalog requirements affect how those records are accessed. Some system tables and optimization capabilities carry preview labels, so a production design must distinguish established monitoring from newer functions rather than treating the complete catalog as uniformly mature.

Databricks leads this editorial assessment because deep analytical architecture is accompanied by operational evidence and integration. It suits organizations connecting warehouse analysis with engineering on shared lakehouse data. Procurement should still specify cloud, region, warehouse type and catalog prerequisites; a serverless configuration documented for one environment is not a promise of identical availability everywhere.

2. Google BigQuery

• Provider / operator: Google
• Headquarters: Mountain View, California, United States
• Provider origins: 1998

Google BigQuery approaches analytical warehousing through distributed execution and managed resource allocation. Queries are divided into stages that consume slots, while organizations can choose between on-demand and capacity-oriented arrangements. This makes the service relevant both to occasional exploration and to managed enterprise workloads, provided teams understand the resource model rather than reading serverless as the absence of planning.

Query plans and execution timelines provide a practical route from a slow result to an investigation. Analysts can examine how work moves through stages, while administrators consider reservations, concurrency and optimization. A slot is an allocation concept, not a fixed promise of query speed. Data layout, query construction and simultaneous demand remain important even when the underlying servers are managed.

BigQuery's Tier I placement reflects that combination of analytical depth and clear diagnostic documentation. It is a strong candidate for teams wanting managed SQL with explicit workload planning choices. Evaluation should compare representative query shapes and consumption patterns, including repeated dashboard refreshes, rather than extrapolating from a single short demonstration or assuming every pricing arrangement behaves alike.

3. Microsoft Fabric Warehouse

• Provider / operator: Microsoft
• Headquarters: Redmond, Washington, United States
• Provider origins: 1975

Microsoft Fabric Warehouse provides an analytical SQL experience within a wider environment organized around OneLake. It is attractive where teams want warehouse tables to participate in a shared data workflow rather than stand apart from engineering and reporting. The comparison evaluates this warehouse product specifically, with the broader Fabric portfolio supplying integration context rather than substituting for warehouse capability.

Microsoft's decision and performance guides help distinguish warehouse-oriented SQL work from lakehouse alternatives. Its security guidance is equally material: permissions enforced through a SQL analytics endpoint do not automatically become equivalent controls for every route to underlying OneLake data. Designers need aligned OneLake rules or restricted alternative access, especially when shortcuts and different consumption paths form part of the architecture.

Fabric Warehouse reaches Tier I through analytical provision and close integration with enterprise data workflows. Its strongest fit is an organization prepared to govern those connected surfaces deliberately. Evaluation should trace the same sensitive dataset through SQL, shared storage and downstream tools, confirming effective permissions and workload behavior instead of assuming one security definition covers every possible access context.

4. Snowflake

• Provider / operator: Snowflake
• Principal executive office: Menlo Park, California, United States
• Provider origins: 2012 (incorporated July 23)

Snowflake treats analytical compute as a resource that teams can allocate independently through virtual warehouses. That makes it useful when reporting, ingestion and exploratory analysis need different operating policies while sharing a managed data environment. Its inclusion concerns the named platform and its documented warehouse controls, with the warehouse operating model as the focus.

The operational detail matters. Administrators can inspect warehouse load, investigate query histories and restrict who creates or changes compute resources. Resource monitors add a further control, but Snowflake explicitly distinguishes warehouse spending from serverless features and cloud services. A credible deployment therefore combines permissions, workload diagnosis and consumption review instead of assuming that one budget setting governs every billable activity.

Snowflake earns Tier I through the depth and clarity of that managed analytical operating model. It suits enterprises seeking SQL capability with configurable workload separation. Buyers should still test representative concurrency, data movement and recovery requirements. The fact box uses its current filing's Menlo Park principal executive office, avoiding an outdated assumption about a conventional headquarters.

5. Amazon Redshift

• Provider / operator: Amazon Web Services
• Headquarters: Seattle, Washington, United States
• Provider origins: 2006 (AWS cloud business)

Amazon Redshift is a managed analytical warehouse with explicit mechanisms for organizing competing SQL workloads. Automatic and manual workload management offer different approaches to queues and resource allocation. The product belongs here because it provides analytical execution and administration as an operating platform; its position does not follow automatically from AWS's broader infrastructure reach or the presence of neighboring services.

Query monitoring rules turn workload policy into configurable behavior. Teams can investigate execution, set priorities and decide how exceptional queries should be handled. Concurrency scaling is another planning mechanism, rather than evidence that every burst will disappear without configuration. Audit and data-sharing guidance add separate questions about who accessed information and how shared datasets are administered across analytical consumers.

Tier I recognizes a mature, inspectable operating model for enterprises with varied reporting and analysis demands. The practical choice still depends on data layout, queue policy and the selected service configuration. Buyers should exercise representative mixed workloads and access changes, because a documented management feature establishes available control while leaving its effectiveness dependent on the deployment's policies.

---

Tier II — Established Cloud Data Warehousing & Lakehouse Platforms

(Alphabetical order)

Alibaba Cloud MaxCompute

• Provider / operator: Alibaba Cloud
• Headquarters: Hangzhou, China
• Provider origins: 2009 (Alibaba Cloud)

Alibaba Cloud MaxCompute is a serverless analytical warehouse with managed storage and compute. Its documented scope includes SQL processing and full or incremental data workflows, making it relevant to enterprises building recurring analytical pipelines rather than purchasing generic object storage. The evaluated unit is MaxCompute, while the fact box identifies Alibaba Cloud's business origins and operating base separately from the product's own release history.

Project administration provides a concrete organizational boundary for data and execution. Current guides describe monitoring, alerts, security and audit-related operation, giving administrators a way to investigate how the managed service is being used. Serverless delivery reduces some infrastructure tasks, but does not remove decisions about projects, permissions, workload organization or the consequences of a poorly designed recurring data-processing job.

Tier II recognizes a managed analytical platform with strong operational documentation. Buyers should test their intended processing cadence, source integration and administrative policy in the relevant service region. A useful comparison examines the complete analytical workflow and consumption arrangement, rather than assuming that the word serverless alone determines cost, governance quality or the behavior of every large query.

ClickHouse Cloud

• Provider / operator: ClickHouse
• Company-declared headquarters: Palo Alto, California, United States
• Provider origins: 2021 (company; open-source project predates it)

ClickHouse Cloud packages column-oriented analytics as an operated service with an architecture designed around cloud resources. Published engineering material explains the separation of compute from object-backed storage, alongside caching and control-plane components. That is a useful foundation for organizations building interactive analytics or serving repeated analytical requests from applications, without turning a particular vendor benchmark into a universal performance conclusion.

The service's operating model includes managed components such as backup and observability. Its architecture has also evolved, so early engineering descriptions need to be read alongside current product and consumption information. Teams should examine how ingestion, query demand and retained data interact in their chosen configuration. A well-defined columnar engine does not make every data layout or concurrency pattern equally appropriate.

Tier II reflects a analytical platform with clear architectural evidence and application-facing relevance. Buyers should test their own ingestion cadence, query shapes and recovery requirements. The founding date refers to the commercial ClickHouse company rather than the earlier open-source project's creation, preserving the distinction between the maintained engine's technical lineage and the current provider's corporate identity.

Cloudera Data Warehouse

• Provider / operator: Cloudera
• Corporate office / provider base: Santa Clara, California, United States
• Provider origins: 2008

Cloudera Data Warehouse provides managed SQL analytics within a wider hybrid data platform. Its relevance is strongest where enterprises need warehouse execution connected to an existing governed data estate. The product's inclusion concerns the cloud analytical service; documentation for an on-premises edition is useful context but does not by itself establish identical cloud functionality or remove deployment-specific operating responsibilities.

Impala workload-management documentation gives a concrete example of why versions matter. Query logging has explicit enablement requirements, and its development progressed from a preview stage to general availability in later cloud releases. Administrators can use the resulting workload records for investigation, but should not assume that every older environment automatically collects the same evidence with the same default settings.

Tier II reflects analytical architecture, platform integration and inspectable controls. It suits organizations prepared to manage the relationship between warehouse execution, data governance and hybrid deployment policy. A procurement exercise should confirm the exact cloud release, logging configuration and engine behavior being purchased, then test how administrators investigate contention and access activity in that environment.

Dremio Cloud

• Provider / operator: Dremio
• Company-declared headquarters: Austin, Texas, United States
• Provider origins: 2015

Dremio Cloud focuses on analytical access to lakehouse data, with SQL execution and managed capabilities around Apache Iceberg tables. That positions it for organizations that want analysis to remain close to open analytical storage rather than requiring every dataset to become a separate proprietary warehouse copy. The current cloud product is the evaluated unit, not an undifferentiated list of Dremio software editions.

Its documentation connects table optimization and clustering with Reflections, which provide materialized acceleration structures that the query system can use. These are design choices, but they introduce questions about freshness, maintenance and the workloads selected for acceleration. Governance and performance administration therefore belong together: a faster analytical path still needs controlled access and an understandable relationship to underlying data.

The Tier II result reflects strong lakehouse architecture and useful openness for analytical integration. Buyers should test how representative queries use Reflections and how table changes affect subsequent analysis. The product is most compelling when its managed optimization and catalog functions simplify a defined lakehouse workflow, rather than when its inclusion is interpreted as a promise that every query avoids physical data management.

IBM watsonx.data

• Provider / operator: IBM
• Headquarters: Armonk, New York, United States
• Provider origins: 1911

IBM watsonx.data presents a lakehouse environment with multiple analytical engines and associated operational tooling. That architecture is relevant when different query or processing requirements must work with a common data estate. Its inclusion is based on maintained analytical storage and execution capabilities, rather than extending the evaluation to every product carrying the wider watsonx name.

Monitoring documentation distinguishes infrastructure, engine workloads and audit activity. Presto query history can persist in object storage across an engine restart, helping teams investigate earlier work without relying entirely on a live process. OpenTelemetry integration offers another route into operational tooling. Deployment-specific manuals remain important because SaaS, premium and other software arrangements do not necessarily expose identical components or responsibilities.

The Tier II placement recognizes architectural breadth and traceable operating controls. Buyers should map each intended workload to its engine, monitoring path and governance arrangements before treating the lakehouse as one uniform execution environment. A evaluation includes restart investigation and permission changes, alongside query execution, because recoverable operational evidence is part of maintaining an analytical platform over time.

Oracle Autonomous AI Lakehouse

• Provider / operator: Oracle
• Headquarters: Austin, Texas, United States
• Provider origins: 1977

Oracle Autonomous AI Lakehouse combines autonomous database services with analytical access to lakehouse data. Its documented scope includes querying Apache Iceberg data in place and bringing that access into a unified catalog. The result is a credible warehouse and lakehouse offering for enterprises that want database-oriented SQL capabilities alongside data held in open analytical table structures.

The product also describes SQL, Spark and Python workflows, which makes integration a more question than simply connecting a dashboard. Teams must understand catalog configuration, data access and where each workload executes. Advertised acceleration is a design proposition that needs workload-specific evaluation; the presence of an optimization mechanism does not establish a universal speed advantage over every competing analytical service.

Tier II reflects strong architecture and governance provision with a clear enterprise use case. Oracle is relevant where database administration and open-table analysis need to coexist. A pilot should examine permissions, external-table freshness and operational responsibilities across those paths, using the exact supported configuration. The provider's founding date describes Oracle's business origins, not the launch date of this current product name.

SingleStore Helios

• Provider / operator: SingleStore
• Company-declared headquarters: San Francisco, California, United States
• Provider origins: 2011 (MemSQL business origins)

SingleStore Helios provides managed SQL infrastructure for workloads that connect operational data with analytical access. That combination gives it a different emphasis from warehouses designed mainly around infrequent batch reporting. Its inclusion rests on maintained managed clusters, SQL capabilities and analytical operation, with the wider SingleStore product lineage supplying context rather than a separate placement in the same list.

Query-performance tools and sizing guidance help teams investigate execution and choose resources. Elastic cluster arrangements and role-based controls provide configurable operating boundaries. Consumption reporting separates compute, storage and transfer, while forecasts are explicitly estimates based on historical patterns. This supports a more useful evaluation than reading a projected bill or a migration comparison as a guaranteed production result.

Tier II recognizes analytical architecture coupled with application integration and inspectable operations. Its particular strength at the band boundary is the documented connection between live application data and analytical serving. Buyers should test that combined workload directly, including contention and resizing, because success in an isolated reporting query does not establish the behavior of a mixed operational and analytical deployment.

Starburst Galaxy

• Provider / operator: Starburst
• Company-declared headquarters: Boston, Massachusetts, United States
• Provider origins: 2017

Starburst Galaxy delivers managed Trino-based analytics across catalogs and data sources. Federation is central to its appeal: organizations can bring analytical questions to a distributed data estate without first assuming that every source must be copied into one warehouse. The product still belongs within this comparison because it supplies a managed analytical execution environment, not merely a connector library or reporting front end.

Catalog, cluster and table privileges provide specific authorization boundaries. Query reports support investigation of how work executed, while security documentation describes control-plane metadata and conditional support access. These details matter when a query crosses organizational or technical boundaries. Federated access can reduce unnecessary duplication, but it does not remove the need to govern source permissions, movement and operational dependencies.

Tier II recognizes considerable analytical breadth and especially strong integration across data environments. Buyers should evaluate realistic cross-source queries, access revocation and source-side constraints. The strongest fit is an organization that values managed distributed SQL and can articulate which datasets should remain in place, which should be materialized, and how failures in connected systems will affect analytical consumers.

Teradata Cloud

• Provider / operator: Teradata
• Headquarters: San Diego, California, United States
• Provider origins: 1979

Teradata Cloud continues a long-established analytical database lineage through current cloud deployment offerings. The VantageCloud Lake documentation describes a model in which compute resources can be organized around different workloads. That is especially relevant to enterprises with sustained SQL analysis and competing operational priorities, where the ability to assign resources deliberately matters as much as a short isolated query demonstration.

Workload-management references explain how administrators monitor resources and direct execution. Those mechanisms provide evidence of configurable operational depth, without establishing that every configuration delivers the same performance. Current product branding and versioned Lake documentation should be read together: an architectural capability described for a specific Lake arrangement is not automatically a feature of every contract or legacy deployment carrying Teradata's name.

Tier II recognizes deep analytical capability supported by detailed workload administration. The strongest evaluation will use a realistic mixture of recurring reporting, exploratory queries and peak demand. Buyers should specify the cloud arrangement, compute grouping and resource policies in scope, then examine workload behavior and access administration under those conditions rather than transferring results from another Teradata architecture without qualification.

Vertica (cloud deployment)

• Provider / operator: Vertica / Rocket Software
• Headquarters: Waltham, Massachusetts, United States
• Provider origins: 1990

Vertica provides a supported analytical database deployment on cloud infrastructure, with Eon Mode separating shared storage from execution organized through subclusters. Its current operator is Rocket Software following the completed acquisition in May 2026. The comparison treats Vertica as one maintained analytical product, preserving the distinction between the database's lineage and the current provider's broader enterprise software portfolio.

Resource-pool architecture gives administrators detailed ways to allocate execution capacity. User assignments, privileges and subcluster resource policies affect how workloads share the system. These controls support enterprise analytical administration, but they also require deliberate configuration. A cloud deployment remains an operating architecture with resource decisions and responsibilities, rather than becoming interchangeable with a fully serverless managed warehouse because its storage resides in the cloud.

Tier II reflects analytical depth, workload control and detailed technical transparency. Buyers should specify deployment mode and subcluster design, then test mixed queries and permission changes. The fact box identifies Rocket Software's provider headquarters and founding; the acquisition does not reset Vertica's technical history or justify counting its former owner as an additional eligible platform.

---

Tier III — Specialist Cloud Data Warehousing & Lakehouse Platforms

(Alphabetical order)

Altinity.Cloud

• Provider / operator: Altinity
• Company-declared headquarters: Berkeley, California, United States
• Provider origins: 2017

Altinity.Cloud is an operated analytical platform built around ClickHouse, with its own environment administration and maintained Kubernetes tooling. It qualifies through the managed service, including cluster creation, monitoring and operational controls, rather than through resale of another provider's commercial cloud product. Sharing an open-source engine with other entries does not make independent operating platforms identical in deployment responsibility or administration.

The service guide explains shards, replicas, queries and data loading. Backup documentation adds decisions about schedules, storage locations and restoration, while environment guides expose configuration responsibilities. Current operator release notes demonstrate maintained supporting software, but the operator alone is not the evaluated warehouse. The relevant offering is the cloud service that brings these components together under a documented division of provider and customer tasks.

Tier III recognizes a technically operating model with clear control and recovery documentation. Buyers should evaluate the selected environment, backup restoration and workload configuration directly. Altinity.Cloud is especially relevant when configurable ClickHouse operation matters, provided the organization understands which platform functions are managed and which surrounding data and application responsibilities remain its own.

Databend Cloud

• Provider / operator: Databend
• Company-declared headquarters: Reno, Nevada, United States
• Provider origins: 2021

Databend Cloud offers managed analytical SQL through warehouses that represent compute resources, including memory and local caching. Those warehouses are used for queries, data modification and loading. The product therefore qualifies as an analytical platform with a defined execution model, rather than as a generic storage service or a new assistant interface layered over an unrelated database.

The cloud documentation explains managed deployment, upgrades and scaling, with availability tied to supported regions. Connection guides describe language drivers and familiar analytical clients. Running a warehouse incurs expense, making resource lifecycle decisions part of ordinary administration. Databend also documents a Cloud Agent as a preview; that newer interface receives no assumption of general availability or established production maturity in this assessment.

Tier III recognizes a coherent cloud warehouse with accessible technical workflows. Buyers should verify regional availability, administrative controls and the behavior of representative SQL loads. The most useful trial connects an existing analytical client, exercises loading and modification alongside queries, and examines how warehouse operation affects consumption, rather than basing the platform decision on preview demonstrations alone.

Exasol SaaS

• Provider / operator: Exasol
• Company-declared headquarters: Nuremberg, Germany
• Provider origins: 2000

Exasol SaaS packages an analytical SQL database as a cloud service with a defined account and database-creation workflow. The product is evaluated as an analytical platform, not simply as a hosted edition inferred from the provider's earlier database history. It is relevant to teams seeking managed SQL analytics while retaining familiar database concepts and integration with an existing reporting or analytical application environment.

Current first-steps documentation identifies supported provisioning choices and an Owner role for actions such as database creation and inviting users. Database users and roles form a separate layer of data administration. That distinction is useful for enterprises: control over the service account and control over analytical data should be mapped deliberately rather than assigned through one undifferentiated administrator assumption.

Tier III reflects a coherent managed warehouse with accessible operational guidance. Buyers should confirm region, migration requirements and the permissions needed for ongoing administration. The most useful trial connects the intended analytical tools, exercises access changes and validates representative SQL behavior, ensuring that the service's documented provisioning simplicity also fits the organization's continuing governance and operational needs.

Firebolt

• Provider / operator: Firebolt
• Company-declared headquarters: Palo Alto, California, United States
• Provider origins: 2019

Firebolt is a focused cloud analytical SQL platform with independent engines and indexing choices that support workload-oriented design. Its appeal is clearest when teams need to serve repeated analytical questions from applications or separate different query demands. The evaluation considers these documented architectural mechanisms; vendor comparisons with competing databases are not adopted as evidence of a general speed or cost advantage.

Migration guidance makes engine sizing and workload testing explicit parts of implementation. Billing and storage-history tables provide additional visibility into resource use, rather than leaving consumption entirely outside the analytical workflow. Separate engines can help organize execution, but they still require decisions about scale, query patterns and data organization. Isolation is a configuration tool, not an automatic guarantee against every bottleneck.

Tier III recognizes a coherent analytical offering with useful technical specificity. Buyers should evaluate representative query patterns and the administrative work required to maintain indexes and engine choices. Firebolt is most relevant when its architecture matches a defined serving workload and the team can monitor both execution behavior and consumption, rather than expecting a single demonstration query to characterize the entire platform.

Huawei Cloud DWS

• Provider / operator: Huawei
• Headquarters: Shenzhen, China
• Huawei provider origins: 1987

Huawei Cloud Data Warehouse Service provides distributed analytical SQL through an MPP architecture with row and column data organization. That makes it a substantive warehouse product for enterprises operating analytical databases in supported cloud environments. Its inclusion is based on documented database and cluster capabilities, rather than on the provider's unrelated infrastructure scale or broad corporate technology portfolio.

Management and best-practice guides describe network isolation, security groups and administrative operation. These controls give teams concrete implementation choices, but their effectiveness depends on configuration and the surrounding identity and network design. Regional documentation should be matched to the intended deployment. A capability described in one service environment is not an automatic statement that every region exposes the same operating arrangement.

Tier III recognizes a analytical service with governance and administration provision. Buyers should examine representative SQL workloads alongside permissions, network paths and cluster operations. Vendor statements about very large datasets or query speed are not treated as common benchmark results here; the relevant question is how the documented architecture and supported deployment meet the organization's analytical requirements.

Imply Polaris

• Provider / operator: Imply
• Company-declared headquarters: San Francisco, California, United States
• Provider origins: 2015

Imply Polaris provides managed real-time analytics built around the Druid ecosystem. Its value proposition is an operated analytical storage and query environment, especially where continuously arriving data must become usable by applications or analysts. The assessment concerns Polaris itself, with the provider's broader Druid involvement treated as relevant lineage rather than an independent reason to place the product above other engines.

Monitoring covers query and ingestion behavior, while metrics export can connect the service with external operational tools. Regional incident information and migration guidance make the service boundary more visible. They do not establish that a contractual availability commitment equals measured uptime, or that moving from another Imply arrangement preserves every operational assumption without design work and configuration review.

Tier III recognizes a well-defined analytical service with practical operating documentation. Buyers should investigate ingestion freshness, query patterns and monitoring integration using their own event streams. The strongest fit is a team that needs managed Druid-oriented analytics and can describe how it will detect data delays, handle source changes and maintain the surrounding application when workload or service conditions change.

MotherDuck

• Provider / operator: MotherDuck
• Company-declared headquarters: Seattle, Washington, United States
• Provider origins: 2022

MotherDuck extends DuckDB into a cloud service while retaining a role for the client. Its hybrid query-processing architecture allows analytical work to be divided between local and cloud execution. That makes it distinctive for analysts and developers who already work with embedded analytical workflows and want to move into shared cloud resources without abandoning the surrounding client-oriented development approach.

A published CIDR architecture paper explains the design and its use of DuckDB extension mechanisms. Cloud database sharing adds a collaboration path, but organizations still need to establish account administration, permissions and the treatment of local data. The paper supports the architectural observation; it is not a current independent benchmark establishing that hybrid execution is faster for every query or dataset.

Tier III reflects a focused and well-explained analytical model with a different enterprise operating emphasis from the largest warehouse suites. Buyers should test how their queries divide work, how shared databases are administered and where data resides during execution. The strongest fit is a team that values the local-to-cloud workflow and evaluates its governance implications as carefully as its convenience.

OcientCloud

• Provider / operator: Ocient
• Company-declared headquarters: Chicago, Illinois, United States
• Provider origins: 2016

OcientCloud is a managed deployment option for Ocient's analytical warehouse, with a specifically described service environment in Chicago. The engine targets demanding analytical SQL, time-series and geospatial work. That concrete managed service establishes eligibility here; the profile does not assume that generic cloud virtual machines automatically turn every version of the provider's software into the same operated product.

The warehouse documents service classes, query priorities and resource limits, alongside role-based access and audit-oriented controls. Standard JDBC, ODBC and Python interfaces connect the engine to analytical tools. Query management also exposes practical behavior such as cancellation, which may depend on reaching an execution pause point. These details are more useful operational evidence than an unqualified claim of immediate intervention or unlimited scale.

Tier III reflects a specialized but analytical platform. Buyers should examine deployment location, workload configuration and integration requirements directly. Vendor claims about comparative energy use or price-performance are not accepted as independently established results here; a defensible evaluation uses the customer's data and operating constraints, including the governance implications of the selected managed location.

PhoenixAI

• Provider / operator: PhoenixAI (formerly CelerData)
• Company-declared headquarters: Menlo Park, California, United States
• Provider origins: 2022 (company-declared; CelerData lineage)

PhoenixAI is the current brand of the business formerly known as CelerData. Its analytical engine and cloud warehouse capabilities continue that product lineage, while current materials also describe BYOC and Anywhere deployment arrangements. The rebrand is treated as continuity of one provider and evaluated offering, rather than as an opportunity to include the old and new names separately.

Warehouse scaling APIs expose concrete resource-management operations. Authorization references describe role-based and identity-based controls, with Apache Ranger integration in the documented software environment. Deployment context remains important: customer-operated Anywhere software and managed cloud arrangements allocate responsibilities differently. Public claims about agent workloads or low latency identify intended uses, but do not establish measured superiority across the other platforms in this article.

Tier III records analytical provision with a clear technical lineage and current documentation. Buyers should specify the exact managed, BYOC or self-operated configuration before evaluating permissions and scaling behavior. Its strongest case is a defined analytical serving workload where StarRocks-based execution and the chosen operating arrangement fit together, supported by representative testing rather than a brand-change announcement alone.

SAP Datasphere

• Provider / operator: SAP
• Headquarters: Walldorf, Germany
• Provider origins: 1972

SAP Datasphere combines analytical modeling, integration and administrative spaces within an enterprise data environment. Spaces provide a way to organize users, models and allocated resources, making the product useful where business data ownership needs an operational expression. Its warehouse relevance comes from this managed analytical environment, rather than from generic reporting or the purchase of consulting-led data projects.

Administrators can inspect flow activity, expensive statements and resource consumption. Space priorities, memory limits and thread settings give teams concrete levers for managing work. These controls also make the operating task visible: a well-modeled analytical asset can still encounter contention or an unsuitable allocation. Source connections, data integration and space administration therefore need to be evaluated as a connected workflow.

Tier III records an established, technically platform whose emphasis differs from the most broadly positioned warehouse architectures. It is relevant for organizations connecting enterprise business semantics with controlled analytical spaces. Buyers should test resource policies and data freshness across representative integrations, ensuring that the modeled business meaning remains dependable when source data changes and multiple teams use the service simultaneously.

SQreamDB (cloud deployment)

• Provider / operator: SQream
• Company-declared headquarters: New York, New York, United States
• Provider origins: 2010

SQreamDB is a columnar analytical SQL database with documented cloud installation options, including an AWS deployment path. It supports serializable transactions and horizontal scaling for concurrent statements. The evaluated offering is the supported cloud-deployed analytical product, rather than an invented fully managed service assumed from the mere fact that software can access cloud object storage.

Current manuals make infrastructure preparation visible, including operating-system and NVIDIA CUDA requirements. SQL clients and external-data access connect the database with analytical tools and cloud-held files. These provisions establish a workable analytical environment, while also leaving administration with the customer. Release notes and installation prerequisites should be matched to the deployment rather than blended with capabilities from an older edition.

Tier III reflects a focused analytical architecture with explicit technical requirements. Buyers should evaluate supported hardware, SQL compatibility, concurrency and the operational work needed to maintain the selected cloud installation. Its inclusion does not claim equivalence with every serverless warehouse: the relevant comparison is whether SQreamDB's documented execution model and deployment responsibilities fit the organization's analytical workload and engineering resources.

Tencent Cloud TCHouse-C

• Provider / operator: Tencent
• Headquarters: Shenzhen, China
• Tencent group origins: 1998

Tencent Cloud TCHouse-C is a managed analytical service based on ClickHouse. It provides a named cloud warehouse offering with cluster administration and analytical execution, rather than being included merely because Tencent operates broad cloud infrastructure. The product name is kept specific so that its capabilities are not confused with the provider's other database or data-warehouse services.

Official documentation describes cluster operation and monitoring. That gives teams a practical foundation for running analytical workloads while relying on the provider for defined service tasks. Contractual service-level material offers additional context about commitments, but it is not evidence of independently observed availability. Buyers still need to examine their selected cluster configuration, access arrangements and the behavior of their own data and query patterns.

Tier III reflects an established managed columnar analytical option with a comparatively focused scope in this assessment. It is relevant where ClickHouse-oriented workloads and Tencent Cloud deployment fit the surrounding architecture. Evaluation should include ingestion, concurrent queries and operational monitoring, while distinguishing supported service behavior from assumptions imported from a different ClickHouse distribution or another provider's managed service.

Tinybird

• Provider / operator: Tinybird
• Company-declared headquarters: New York, New York, United States
• Provider origins: 2019

Tinybird connects managed analytical data with SQL and application-facing delivery. Data Sources and Pipes organize the route from stored information to queries and published endpoints. It belongs in this comparison because analytical storage and execution are part of the service, not simply because an API gateway can forward requests to an external warehouse or because a dashboard can display numbers.

Its query documentation distinguishes a general SQL API, reusable query logic and endpoint contracts. A ClickHouse-compatible interface provides another integration path. Those distinctions matter for teams turning exploration into an application feature: an ad hoc query and a maintained production endpoint have different stability, access and operational expectations, even when they use closely related SQL expressions over the same underlying data.

Tier III reflects a focused platform for developers building analytical data products. Buyers should evaluate schema changes, endpoint behavior and workspace administration as one workflow. Tinybird's inclusion is relevant where application integration is central to the requirement, while organizations seeking a broad enterprise warehouse should compare its operating scope against their own governance and analytical workload needs.

VeloDB Cloud

• Provider / operator: VeloDB
• Company-declared headquarters: Sunnyvale, California, United States
• Provider origins: May 2023

VeloDB Cloud delivers a managed analytical warehouse built on Apache Doris. Its documented data model includes tables, partitions, buckets and indexes, alongside lakehouse catalogs and ordinary loading and export operations. This makes it a substantive storage and query platform for analytical use, rather than a reseller-only listing or an application that merely displays results from another warehouse.

Current guides cover data changes and optimization as well as resource groups for workload management. Those controls help teams reason about competing query demands. The provider distinguishes SaaS and BYOC cloud offerings from its self-managed enterprise distribution, so evaluation should identify the selected arrangement instead of assuming all installation and operational responsibilities are identical across the portfolio.

Tier III recognizes a technically coherent platform with useful real-time analytical and ecosystem integration. Buyers should test ingestion changes, query concurrency and the isolation policies they expect to operate. The company's 2023 founding is distinct from Apache Doris's earlier project history; the fact box uses VeloDB's current provider identity rather than assigning the open-source engine's entire history to the commercial company.

Yellowbrick

• Provider / operator: Yellowbrick Data
• Headquarters: Mountain View, California, United States
• Provider origins: 2014

Yellowbrick's SQL data platform is organized around controlled analytical deployment, including operation inside customer cloud accounts. The provider describes this as a private data cloud, with cloud and on-premises choices for enterprises that need a deliberate infrastructure boundary. Its inclusion concerns a maintained analytical warehouse architecture, rather than treating private deployment alone as proof of security or performance superiority.

Versioned technical documentation describes virtual compute clusters and lifecycle controls, including suspension and resumption. Resource priorities and workload configuration provide ways to organize analytical demand. These mechanisms still need operating policies: the ability to suspend compute does not determine when a critical workload should resume, and deployment inside a customer account does not replace identity, network or data-access administration.

Tier III recognizes deep warehouse engineering with a particular emphasis on customer control. Buyers should test the chosen cloud configuration, mixed workload behavior and cluster lifecycle operations. The fact box refers to Yellowbrick Data, founded in 2014 and headquartered in Mountain View, preserving the distinction from unrelated organizations that share the Yellowbrick name and operate in entirely different sectors.

---

Remarks

The private assessment scores each criterion on a defined editorial scale and applies the published weights before assigning five, ten and fifteen entries to the three bands. Ties are reviewed against documented technical priorities. The numerical detail supports internal consistency; it is not presented as externally measured precision.

Architectures in this market deliberately differ. A customer-operated cloud database, a federated query service and a serverless warehouse can all qualify while assigning different work to the buyer. Their placement does not erase those responsibilities or make one procurement configuration interchangeable with another.

Organizations should reproduce representative data volumes, query shapes and concurrency in a pilot, then include permission changes, operational diagnosis and resource-policy adjustments. Marketing comparisons should be tested under disclosed conditions rather than transferred into an assumption of universal performance.

The profiles describe current documented provision at the research date. A lower band can still contain the most suitable product for a particular application, ecosystem or deployment policy. Final selection should follow the required analytical workflow and its continuing operational obligations.

---

Recognition

Inclusion in the Top 30 Cloud Data Warehousing & Lakehouse Platforms 2027 ranking is an editorial determination of The Economy Rankings and does not require licensing, advertising, sponsorship, or other commercial participation.

Ranked organizations may factually refer to their inclusion in the ranking in their own communications. When describing the result, entities should accurately reflect the tier structure and methodology used in the published ranking.

How the ranking should be interpreted

• Tier I represents the Top 5 entities, and the published order within Tier I reflects the ranking order.
• Tier II represents entities ranked within the Top 15, following Tier I. Entities within Tier II are displayed alphabetically; their displayed order should therefore not be interpreted as an individual numerical ranking.
• Tier III represents entities ranked within the Top 30, following Tiers I and II. Entities within Tier III are also displayed alphabetically, and their displayed order should not be interpreted as an individual numerical ranking.
• An entity's tier, rather than its alphabetical position within Tier II or Tier III, should therefore be used when describing its standing.

Referencing the ranking

Depending on the entity's published tier, appropriate factual descriptions may include:

• Tier I: “Ranked Tier I” or “Ranked among the Top 5”
• Tier II: “Ranked Tier II” or “Ranked among the Top 15”
• Tier III: “Ranked Tier III” or “Ranked among the Top 30”

Entities should not describe an alphabetical position within Tier II or Tier III as a specific numerical rank.

Use of The Economy Rankings recognition materials

Editorial inclusion in a ranking does NOT by itself grant permission to use The Economy Rankings badges, seals, logos, official recognition graphics, licensed quotations, or other proprietary recognition materials.

Organizations wishing to use official The Economy Rankings recognition materials in corporate websites, marketing materials, investor communications, client presentations, social media, press releases, or other external communications should refer to the applicable licensing terms and usage policies:

• The Economy Rankings License Structure — available licence levels and permitted recognition uses
  The Economy Rankings License Structure | The Economy Rankings
• The Economy Rankings License Policy — licensing conditions governing use of The Economy Rankings recognition, marks, and related materials
  The Economy Rankings License Policy | The Economy Rankings
• Recognition Use Guide — guidance on permitted wording, presentation, attribution, and use of ranking recognition
  Recognition Use Guide | The Economy Rankings

Purchasing or holding a recognition-materials licence does not confer inclusion or a higher tier.

Recognized organizations may reference the designation in:

• corporate websites
• investor communications
• marketing materials
• client presentations

Licensing inquiries:
[email protected]