Cloud Data Warehouse History and Timeline - Separation of Storage and Compute, Open Table Formats, and Convergence with the Data Lake

First Published:
Last Updated:

This article covers the history and timeline of cloud data warehouses as a category. Earlier articles in this series have published timelines for individual services such as Amazon S3, Amazon RDS, Amazon Aurora, Amazon DynamoDB, Amazon Redshift, AWS Glue, and Amazon Athena. However, those timelines focused on a single service each. This article addresses a category spanning multiple vendors, rather than focusing on a single product.

Cloud data warehouses are often marketed with similar descriptions: they eliminate the need to manage clusters, offer independently scalable storage and compute, and allow reading files from data lakes using the same SQL. Amazon Redshift, Snowflake, Google BigQuery, and Databricks did not start from the same design, however. The order in which they arrived, and the words they used when they got there, differ.

One question sits at the center of this article: how should compute and the place where data sits be divided? Each company answered that question at a different time and in a different way. The value of this article lies in setting out the order in which those answers came, and what a later product was able to take for granted because an earlier one had already solved it. It is not a table that compares features at a single point in time.

How Each Vendor Words the Split Between Storage and Compute
How Each Vendor Words the Split Between Storage and Compute
This article does not evaluate the merits of any particular product. It does not rank the products, and it does not suggest moving from one to another. What it records is what each company stated in its own primary sources, and when. Writing down the order in which products arrived is a different thing from ranking them.

This article does not include pricing information. It will not discuss specific costs, discount rates, or cost savings. The focus remains on the structural changes related to billing models. Furthermore, this article will not include performance comparisons. Even where a primary source carries a speed figure, this article does not reproduce it.

The feature history of Amazon Redshift belongs to the earlier article AWS History and Timeline regarding Amazon Redshift. This article treats Amazon Redshift as one product inside a category, taking only the rows that mark turning points for the category. Information on Azure Synapse Analytics and Microsoft Fabric can be found in the previously published Microsoft Azure History and Timeline, which details relevant dates. AWS Data Lakehouse Architecture Guide covers the design of a data lakehouse on AWS, and Zero-ETL Integrations on AWS covers data ingestion pathways from operational databases.

Background and Method of Creating the Cloud Data Warehouse Timeline

There are three reasons for building a timeline that runs across this category.

First, while timelines exist for individual products, there is no timeline for the entire category. While individual products have official release notes, and this site includes a timeline for Amazon Redshift, reading that timeline does not show when Snowflake answered the same question. Readers often find themselves uncertain when comparing products against one another.

Second, the separation of storage and compute is often presented as a single event. In reality, four different companies arrived at this concept in separate years, in different ways, and using different terminology. Reading the primary sources shows that the words each company uses, and the kind of document those words appear in, differ from company to company.

Third, as warehouses and data lakes have converged as implementations, which side a product came from has become hard to tell. Some products started inside the warehouse and reached out to read files in the lake. Others started on the lake and added warehouse behavior to the files there. Looking only at the present shape, those two origins are no longer visible.

The Primary Sources This Article Used

⛔ This article switches its primary source from row to row. It never uses AWS material to support a date that belongs to another vendor.

  • Amazon Redshift: AWS What's New, AWS News Blog, and the Amazon Redshift Management Guide and Database Developer Guide.
  • Snowflake: Release notes from docs.snowflake.com, the Snowflake official blog, and the SIGMOD 2016 paper published by Snowflake itself.
  • Google BigQuery: The Google Cloud blog, documentation and release notes from docs.cloud.google.com, and the Google Developers Blog.
  • Databricks: The blog and news releases on databricks.com, and the CIDR 2021 paper.
  • Apache Iceberg and Apache Polaris: Records from the Apache Software Foundation's incubator, and the official websites for each project.
  • Prehistory: The officially published PDF of each academic paper.

⛔ This article does not cite secondary media or summary articles. There are certain details, such as founding years, acquisition dates, and funding rounds, that cannot be verified through primary sources and are only found in secondary media. This article does not soften such items and write them anyway; it leaves them out. There are instances where this decision resulted in the exclusion of certain information. For example, the company introduction page on the Teradata website, as of the time this article was written, does not list the company's founding year or the year of its first product. Therefore, this article does not mention Teradata's founding year.

⛔ This article avoids phrasing that implies a product was the first of its kind. It is fundamentally impossible to prove that a product was the first using primary sources. Even where a company states as much in its own materials, this article does not take that claim as a fact.

Why the Date Precision Differs from Row to Row

⛔ No day has been added by estimation to make the dates uniform. Rows where the primary sources only state the month are left with the month's precision. The Date column in the timeline carries values with no day, such as 2015-06. A value with no day means that the primary source itself states nothing finer. This is not due to any omissions.

There are four rows that use only the month's precision. These relate to Snowflake's general availability, the publication of a paper describing its design, the paper that gave lakehouse a definition, and the point at which Snowflake put Apache Iceberg tables out as a preview. Each row gives its own reason.

Furthermore, there may be instances where different primary sources cite different dates for the same event. This timeline includes examples such as a two-day discrepancy between a Google blog post and its release notes, and a one-day discrepancy between a Databricks blog post and a news release. The corresponding rows indicate which date was chosen and the reasoning behind that choice.

The Vendor Column and the Track Column

Each row in the timeline includes a Vendor column. Because this is a cross-vendor timeline, a reader has to be able to tell at a glance which vendor a row belongs to. The column takes five values: AWS, Google, Snowflake, Databricks, and Apache. Here Apache refers to changes inside projects managed by the Apache Software Foundation, not to a single product.

Each row also includes a Track column. This column has five possible values, two of which record the status of a product, while the remaining three record the three movements this article follows.

The two values that record product status are:

  • Launch: Indicates that a product has become available. Each row states whether it was a preview or general availability.
  • Lifecycle: Represents changes to a product's name or changes to its availability status.

The three movements this article follows are:

  • Architecture: A change in how compute and the place where data sits are divided.
  • Format: An open table format or a catalog moving outside a single company's product.
  • Convergence: The warehouse engine and the data in the lake coming to be handled in the same place.

Clicking a column header sorts the table. Sorting by Track groups the rows so that any one of the three movements reads straight through.

The Techniques the Cloud Warehouses Inherited

Cloud data warehouses did not begin from nothing. At least two of the techniques used inside the warehouse had already been published as papers before the cloud.

One is column-oriented storage. The paper C-Store: A Column-oriented DBMS, presented at VLDB in 2005, described a relational database design that reads and writes data in columns rather than rows. Seven years later, the same conference hosted The Vertica Analytic Database: C-Store 7 Years Later, which stated that the design was a commercialization of the design of the C-Store research prototype. In other words, the company behind a column-oriented data warehouse product explicitly acknowledged that it was a commercial application of research.

The second is spreading one query across many nodes and running it there. The same Vertica paper described itself as a distributed massively parallel RDBMS system and, in a footnote, stated that it uses the term distributed database to mean a shared-nothing, scale-out system. shared-nothing is where Snowflake's own paper opens when it explains its design. Its Section 2 begins Shared-nothing architectures have become the dominant system architecture in high-performance data warehousing, and names the drawback it sets out to avoid: it tightly couples compute resources and storage resources.

Alongside those two, Google published a paper detailing the design of an engine it was already using internally. The paper Dremel: Interactive Analysis of Web-Scale Datasets, presented at VLDB in 2010, stated, By combining multi-level execution trees and columnar data layout, it is capable of running aggregation queries over trillion-row tables in seconds. Columnar storage, an element of the prehistory, enters a cloud-side implementation here.

This article's timeline does not carry these earlier papers as rows. Presenting the publication dates of these papers alongside the product launch dates in the same column would create a misleading sense of equivalence. The earlier history is therefore handled in prose, and the timeline begins with the availability of cloud-based products.

This article carries no timeline of the on-premises products themselves. As written above, neither the founding year nor the year of a first machine could be confirmed in primary sources. The account of the first generation as tying compute and storage into one device comes from the later paper that defined the lakehouse. That paper states, they typically coupled compute and storage into an on-premises appliance, referring to this as the first generation.

Cloud Data Warehouse Historical Timeline (Updates from May 19, 2010)

The following is a timeline of the cloud data warehouse as a category. It is not exhaustive; it takes only the events that mark turning points for the category. Details on individual product features can be found in their respective timelines and official release notes.

Use the following index to navigate to specific years:

  • 2010 - BigQuery appears as a preview for a limited number of developers
  • 2012 - BigQuery becomes generally available, and Amazon Redshift is announced as a limited preview
  • 2013 - Amazon Redshift becomes generally available
  • 2015 - Snowflake becomes generally available
  • 2016 - Snowflake publishes its architecture and articulates its design in its own terms
  • 2017 - Amazon Redshift begins scanning data lake files on a separate fleet
  • 2018 - Apache Iceberg joins the Apache Incubator
  • 2019 - Delta Lake is released, and Amazon Redshift launches RA3
  • 2020 - The word lakehouse reaches the public, and Apache Iceberg graduates from the Incubator
  • 2021 - The word lakehouse is given a definition, and BigQuery Omni reaches three clouds
  • 2022 - Amazon Redshift Serverless and BigLake become generally available
  • 2023 - Data held as Delta becomes readable as Iceberg, and Snowflake ships Iceberg tables
  • 2024 - Snowflake, Databricks, and Google all ship Apache Iceberg tables or catalogs in the same year
  • 2025 - Catalog APIs are opened to external engines, and warehouses begin writing to lake tables
  • 2026 - The catalog becomes an Apache project, and lake scanning returns to the warehouse

DateVendorTrackSummary
2010-05-19GoogleLaunchBigQuery was announced at Google I/O. The announcement introduced two developer tools, BigQuery and the Prediction API, and described BigQuery as running interactive analysis with SQL over datasets that hold trillions of rows. At this point it was a preview open to a limited number of developers; access required signing up for an invitation, and the announcement states there was no charge during the preview. It opened to the public two years later. References: BigQuery and Prediction API: Get more from your data with Google
2012-05-01GoogleLaunchBigQuery became generally available. The announcement stated, Today, we are making BigQuery publicly available. It also mentioned, Since announcing BigQuery in limited preview last November, indicating that the limited preview was announced in November of the previous year, although the exact date was not specified. This article therefore places this row at 2012-05-01 and does not give the limited preview a row of its own. References: Google BigQuery brings Big Data analytics to all businesses
2012-11-28AWSLaunchAmazon Redshift was announced at re:Invent. At the time of the announcement, it was a limited preview. It was presented as a fully managed data warehouse service capable of handling petabyte-scale data and accessible through standard SQL tools and BI applications. An earlier Amazon Redshift timeline already holds the feature history of this product, so this article takes only the rows that mark turning points for the category. References: Announcing Amazon Redshift
2013-02-15AWSLaunchAmazon Redshift became generally available. Following the limited preview, it was opened to all customers and described as a managed, massively parallel processing (MPP) column-oriented data warehouse, capable of starting small and scaling to petabytes, and compatible with widely used SQL and BI tools. This occurred approximately nine and a half months after the general availability of BigQuery. References: Amazon Redshift - Now Broadly Available
2015-06SnowflakeLaunchSnowflake became generally available. The date comes from a paper Snowflake published at SIGMOD 2016, which states Implementation began in late 2012 and Snowflake has been generally available since June 2015. ⚠ This primary source only specifies the month. This article keeps the month as it stands and adds no estimated day. References: The Snowflake Elastic Data Warehouse
2016-06SnowflakeArchitectureSnowflake published its architecture in a paper. The paper gives its Section 2 the title STORAGE VERSUS COMPUTE and states For these reasons and others, Snowflake separates storage and compute. The paper then names the resulting design itself: We call this novel architecture the multi-cluster, shared-data architecture. The three layers are Data Storage, Virtual Warehouses, and Cloud Services. ⚠ The conference ran from June 26 to July 01, 2016, and the paper itself does not state a publication day. References: The Snowflake Elastic Data Warehouse
2017-04-19AWSArchitectureAmazon Redshift Spectrum was announced. It became possible to directly execute SQL queries on data stored in Amazon S3 without loading the data into a cluster. A separate set of dedicated servers handles the scanning process. This shape, in which the scan is handed to a separate fleet, is folded away once in 2026. Redshift Spectrum as seen from Amazon Athena belongs to the Amazon Athena timeline in this series, so this article approaches it only from the Amazon Redshift side. References: Amazon Redshift Spectrum - Exabyte-Scale In-Place Queries of S3 Data
2018-11-16ApacheFormatApache Iceberg joined the Apache Incubator. The Apache Software Foundation records Project enters incubation under the date 2018-11-16. The same page describes Iceberg as a table format for large, slow-moving tabular data. Nothing on that page says it would later become the ground on which four companies read and write the same tables. References: Iceberg Project Incubation Status
2019-04-24DatabricksFormatDelta Lake was released as open source. It is described as a storage layer designed to bring ACID transactions and snapshot isolation to data lakes. What is added sits on the lake side. The properties the warehouse used to hold are placed on top of the files in the lake. References: Open Sourcing Delta Lake
2019-10-16DatabricksFormatDelta Lake moved to be hosted by the Linux Foundation. While maintaining the Apache 2.0 license, it adopted an open governance model. ⚠ Later articles from Databricks themselves sometimes describe the 2019-04 release and the transition to the Linux Foundation as a single event. This article keeps the two announcement dates as two separate rows. References: Delta Lake Now Hosted by the Linux Foundation to Become the Open Standard for Data Lakes
2019-12-03AWSArchitectureAmazon Redshift announced the RA3 node type. This offering includes managed storage, allowing users to scale compute and storage independently and pay for them separately. ⛔ AWS does not call this configuration a separation. The Amazon Redshift documentation states the result instead: enable you to optimize your data warehouse by scaling and paying for compute and managed storage independently. It does name the action with a verb elsewhere in the same guide, in a section titled Understanding how RG and RA3 nodes separate compute and storage. A second verb sits in the Analytics Lens of AWS Well-Architected, where the best practice is titled Decouple storage from compute and its body states Amazon Redshift RA3 instance types support the ability to decouple the compute and storage. References: Amazon Redshift announces RA3 nodes with managed storage / Amazon Redshift provisioned clusters / Considerations for using Amazon Redshift provisioned clusters / Best practice 11.1 - Decouple storage from compute
2020-01-30DatabricksConvergenceDatabricks used the word lakehouse in a published article. The article defines the term as A lakehouse is a new, open architecture that combines the best elements of data lakes and data warehouses and describes the design as implementing similar data structures and data management features to those in a data warehouse directly on top of low cost cloud storage in open formats. This word becomes the name of the end point this article arrives at. References: What Is a Data Lakehouse?
2020-05-20ApacheFormatApache Iceberg graduated from the Incubator and became a top-level project. The Incubator record states Graduated from the incubator under the date 2020-05-20. That is one and a half years after it entered incubation. References: Iceberg Project Incubation Status
2020-07-15GoogleArchitectureBigQuery Omni was announced. It brings data that sits in another public cloud within reach of the BigQuery interface. The announcement states that BigQuery Omni is currently in private alpha. ⛔ What stands out is how the announcement gives its reason: it writes which is made possible by BigQuery's separation of compute and storage. Naming the split as the ground on which the feature stands is what marks this announcement out. References: BigQuery Omni for multi-cloud data analytics
2021-01DatabricksConvergenceThe paper that gave lakehouse a definition was published at CIDR 2021. The paper states We define a Lakehouse as a data management system based on low-cost and directly-accessible storage that also provides traditional analytical DBMS management and performance features such as ACID transactions, data versioning, auditing, indexing, caching, and query optimization. The paper calls the generation in which an on-premises appliance tied compute and storage together the first generation, the data lake the second, and places the lakehouse next. ⚠ The published PDF carries no date, so this row is placed with the precision of a month. References: Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics
2021-10-27GoogleArchitectureGoogle announced that BigQuery Omni was reaching three clouds. The announcement stated, For the first time, customers will be able to perform cross-cloud analytics from a single pane of glass, across Google Cloud, Amazon Web Services (AWS) and Microsoft Azure. ⚠ However, the same section also states, BigQuery Omni will be available to all customers on AWS and for select customers on Microsoft Azure during Q4, so it does not say that everyone could use it on all three clouds at once. This article does not treat this row as a general availability row. References: Analyze data across clouds with BigQuery Omni
2022-07-12AWSArchitectureAmazon Redshift Serverless became generally available. It runs and scales analytics without provisioning or managing clusters. ⚠ Amazon Redshift Serverless is the product name, and this article does not use serverless as an adjective in its own prose. The rule the three articles in this series share is narrower: each uses the word only for what its own primary source applies it to. References: Amazon Redshift Serverless is now generally available
2022-07-27GoogleConvergenceBigLake became generally available. The announcement describes BigLake as a storage engine that extends innovations in BigQuery storage to open file formats running on public cloud object stores. This is the move that carries the storage layer built inside the warehouse out to open file formats on object storage. ⚠ This product will be rebranded in 2026. References: Unify data lakes and warehouses with BigLake, now generally available
2023-06-28DatabricksFormatDatabricks announced the Universal Format for Delta Lake 3.0. The announcement states Now, data stored in Delta can be read from as if it were Iceberg or Hudi and explains the mechanism as automatically generates metadata needed for Iceberg or Hudi, and thus unifies the table formats so users don't have to choose or do manual conversions between formats. Instead of choosing a single format, this approach allows a single entity to be read in multiple formats. References: Announcing Delta Lake 3.0: New Universal Format Offers Automatic Compatibility for Apache Iceberg and Apache Hudi
2023-11SnowflakeFormatSnowflake released a preview of Apache Iceberg tables. The release notes state that Iceberg tables keep the performance and query semantics of a regular Snowflake table while using external cloud storage that the customer manages. ⚠ The source is the 7.42 release notes, and the heading spans November 29-30, 2023, so this row is placed with the precision of a month. References: November 29-30, 2023 - 7.42 Release Notes
2024-06-03SnowflakeFormatSnowflake announced the Polaris Catalog. Snowflake presented it as an open catalog for Apache Iceberg and named systems that can use it, such as Apache Doris, Apache Flink, Apache Spark, PyIceberg, StarRocks, Trino. ⚠ At this point, the announcement only stated that Polaris Catalog will be both open sourced in the next 90 days, and did not mention a donation to the Apache Software Foundation. References: Polaris Catalog: An Open Source Catalog for Apache Iceberg
2024-06-13DatabricksFormatUnity Catalog was released as open source. The article states that it is compatible with Apache Hive's metastore API and Apache Iceberg's REST catalog API and notes that Unity Catalog is hosted at LF AI & Data, an umbrella foundation of the Linux Foundation. ⚠ Databricks' own news release, announcing the same development, was dated June 12. This article uses the date of the blog post, whose body states the date. References: Open sourcing Unity Catalog, creating the industry's only universal catalog for data and AI
2024-06-21SnowflakeFormatSnowflake's Iceberg tables became generally available. The article states, Iceberg tables (now generally available), unlocking full storage interoperability. This lands 18 days after the Polaris Catalog announcement, so the catalog and the tables both arrive in the same month. References: Open Storage with Iceberg Tables Now Generally Available
2024-10-12GoogleFormatBigQuery tables for Apache Iceberg were announced as a preview. The article describes the feature as allowing users to use the Apache Iceberg format to store data in customer-owned cloud storage buckets while providing a similar customer experience and feature set as BigQuery native tables. ⚠ Google's own release notes list this item as October 10, 2024, two days earlier than the blog post. This article takes the date of the blog post, whose body says Today. ⚠ This feature is called Apache Iceberg managed tables in the current documentation. References: Announcing BigQuery tables for Apache Iceberg / Apache Iceberg managed tables
2024-10-18SnowflakeFormatPolaris Catalog was renamed Snowflake Open Catalog, and its integration with Iceberg tables reached general availability. The release note carries the new name in its title. The name changed during the four and a half months between the announcement and general availability. References: Apache Iceberg tables: Support for Snowflake Open Catalog - General Availability
2025-06-12DatabricksFormatUnity Catalog added support for the Iceberg REST Catalog API. The article states Full support for the Iceberg REST Catalog API, indicating that reading from external engines is Generally Available while writing is in Public Preview. The availability status differs between reading and writing. The same article also announces managed Iceberg tables as a Public Preview feature. References: What's new with Databricks Unity Catalog at Data + AI Summit 2025
2025-11-17AWSConvergenceAmazon Redshift gained the ability to write to Apache Iceberg tables. Read and write queries for append-only workloads can now run from inside Amazon Redshift. This marks a shift, with the warehouse engine now writing to tables that sit in the lake. References: Amazon Redshift now supports writing to Apache Iceberg tables
2026-02-19ApacheFormatApache Polaris graduated from the Incubator and became a top-level project. The announcement describes Polaris as a cloud-native, open-source catalog for Apache Iceberg and a centralized service to manage your data across different engines and clouds. After the format, the catalog too stopped being one company's product and became an Apache project. References: Apache Polaris Graduates to Top Level Project!
2026-03-04SnowflakeFormatSnowflake added preview support for version 3 of the Apache Iceberg table specification. The release notes state that support for version 3 of the Apache Iceberg table specification is in public preview. Services do not move in step on the same format version 3. The AWS Glue timeline and the Amazon Athena timeline in this series each cover where AWS stands. References: Support for Apache Iceberg version 3 (Preview)
2026-04-20GoogleLifecycleBigLake was renamed. The documentation states As of April 20th, 2026, BigLake is now called Lakehouse. BigLake metastore is now called the Lakehouse runtime catalog. Configurations spanning multiple clouds are referred to as borderless Lakehouse. ⛔ The general availability announcement of 2022 still carries the old name, so the names do not line up when reading older material. References: What is borderless Lakehouse?
2026-05-12AWSConvergenceAmazon Redshift released RG instances powered by AWS Graviton. The announcement states that RG instances include Redshift's custom-built vectorized data lake query engine that processes Apache Iceberg and Parquet data on your cluster nodes, and further states that this removes the need for Redshift Spectrum's separate scanning fleet. This marks a shift, as data lake scanning, previously placed on a separate fleet, has returned to the cluster's own compute resources. Current documentation states we recommend choosing RG or RA3 depending on the required performance, data size, and expected data growth. Another page states that On RG provisioned clusters, data lake queries run on the cluster's own compute resources and share those resources with other workloads. References: Amazon Redshift launches RG instances powered by AWS Graviton / Considerations for using Amazon Redshift provisioned clusters

Current Overview of Cloud Data Warehouses

How Each Vendor Words the Split

This article uses the phrase separation of storage and compute as an umbrella for the question the whole category faces. However, this is a term used for the purposes of this article and is not a universally shared term used by all companies. In the primary sources, the four companies describe this concept in four different ways.

Snowflake uses the title STORAGE VERSUS COMPUTE for Section 2 of the paper describing its architecture. The text reads, For these reasons and others, Snowflake separates storage and compute, and continues, The two aspects are handled by two loosely coupled, independently scalable services. From this, they have created their own name for the resulting configuration: We call this novel architecture the multi-cluster, shared-data architecture.

This same terminology appears in Snowflake's current documentation, Snowflake key concepts and architecture. It states, Snowflake separates storage and compute, which simplifies some traditional challenges of data engineering. ⚠ The architecture section on that same page, however, places a different description beside it. It reads, Snowflake's architecture is a hybrid of traditional shared-disk and shared-nothing database architectures, and continues, Similar to shared-disk architectures, Snowflake uses a central data repository for persisted data that is accessible from all compute nodes in the platform. The verb separates and the description of a hybrid of two classical architectures therefore sit side by side on the same page.

Google writes this idea as a noun and uses it as the ground on which a feature stands. Current documentation, BigQuery overview, states BigQuery's architecture consists of two parts: a storage layer that ingests, stores, and optimizes data and a compute layer that provides analytics capabilities and continues BigQuery's separation of compute and storage layers lets each layer dynamically allocate resources without impacting the performance or availability of the other. The 2020 announcement of the feature that reaches data in another cloud gives the reason as which is made possible by BigQuery's separation of compute and storage, again in the noun form.

AWS writes it as a verb, and it writes it in two kinds of document with two different verbs. The Amazon Redshift service documentation states the result for the RG and RA3 nodes: enable you to optimize your data warehouse by scaling and paying for compute and managed storage independently. The noun separation does not appear there. The verb does: a section of the Amazon Redshift Management Guide is titled Understanding how RG and RA3 nodes separate compute and storage, which is the same verb Snowflake uses. A second verb sits in the AWS Well-Architected Analytics Lens, where the best practice is titled Decouple storage from compute and its body states Amazon Redshift RA3 instance types support the ability to decouple the compute and storage. ⛔ For AWS, then, the idea is named in both places, and the two places do not use the same verb.

Databricks writes about placing rather than splitting. The article of January 30, 2020 defines the term as A lakehouse is a new, open architecture that combines the best elements of data lakes and data warehouses. What that assumes is a shape in which warehouse behavior is placed on top of inexpensive object storage. Because the starting point is the lake side, the description is not written from the splitting side at all.

⛔ The same idea surfaces under separates, separation, decouple, and independently, and it sits in four different kinds of document: a research paper, service documentation, design guidance, and a blog post. Only the verb separate is shared, by Snowflake's paper and by one section title in the AWS service documentation; every other word belongs to one company. Summarizing all of it under one word would still give the false picture that the four companies declared the same thing in the same words. This article quotes each company sentence by sentence in the timeline so that the difference is not erased.

Where the Word Lakehouse Was Defined

lakehouse is now a word all four companies use. Its origin, however, is clear.

Among the primary sources this article checked, the earliest one that explains this term is an article from Databricks. The article, dated January 30, 2020, states A lakehouse is a new, open architecture that combines the best elements of data lakes and data warehouses and describes the design as implementing similar data structures and data management features to those in a data warehouse directly on top of low cost cloud storage in open formats.

One year later, the same authors provided a definition in a research paper. The CIDR 2021 paper states: We define a Lakehouse as a data management system based on low-cost and directly-accessible storage that also provides traditional analytical DBMS management and performance features such as ACID transactions, data versioning, auditing, indexing, caching, and query optimization.

The paper places this word inside an account of generations. The first generation is the data warehouse, which tied compute and storage together in an on-premises appliance. The second generation is the data lake, which moved raw data onto inexpensive storage. The paper presents the lakehouse as the third generation, and defines it as putting the management features the second generation lacked, such as ACID transactions and indexing, on top of the second generation's inexpensive and directly accessible storage.

⚠ Part of what the paper argues is not taken as fact by this article. The abstract predicts that the data warehouse architecture as we know it today will wither in the coming years, this is a claim made by the paper and not a verifiable fact. This article takes only when, where, and how the term was defined.

What the Open Table Formats Made Possible

Of the 31 rows in this timeline, 14 carry Format in the Track column. The process by which the warehouse and the lake converged as implementations shows up in the timeline as movement in open table formats and catalogs.

Between 2018 and 2020, open table formats moved outside a single company's product. Apache Iceberg joined the Apache Incubator in November 2018 and graduated to become a top-level project in May 2020. Delta Lake was released as open source in April 2019 and transitioned to become a project hosted by the Linux Foundation in October of the same year.

What came next was a different answer: rather than settling on one format, let one body of data be read as several formats. The announcement of Delta Lake 3.0 in 2023 stated Now, data stored in Delta can be read from as if it were Iceberg or Hudi. The mechanism is that the required metadata is generated automatically.

In 2024, three companies, Snowflake, Databricks, and Google, each shipped an Apache Iceberg table or catalog in the same year. Snowflake announced Polaris Catalog in June and made Iceberg tables generally available later that same month. Databricks released Unity Catalog as open source in June, stating that it was compatible with the Apache Iceberg's REST catalog API. In October, Google put out as a preview a shape that holds data in Iceberg format inside the customer's own storage buckets. The ability for AWS's Amazon Redshift to write to Apache Iceberg became available on November 17, 2025. The following articles in this series cover where AWS stands: AWS History and Timeline regarding AWS Glue and AWS History and Timeline regarding Amazon Athena.

After the formats, the catalogs stopped belonging to a single product as well. Polaris, announced by Snowflake, became an Apache top-level project in February 2026.

⚠ Services do not move in step on the same format, however. Support for version 3 of the Apache Iceberg table specification is not at the same stage across services. Snowflake states that it reached public preview in March 2026. The other two articles in this series cover where AWS stands. This article does not write the release history of Apache Iceberg itself. It records only when each product added support.

Where the Two Starting Points Meet Today

Products originating from the warehouse side and those originating from the lake side are now handling the same data and the same tables in the same location. However, the paths they took to get there are reversed.

Where the Warehouse and the Data Lake Meet
Where the Warehouse and the Data Lake Meet
Products originating from the warehouse side have added an external layer to access files from the lake. In 2017, Amazon Redshift introduced a system where a dedicated set of servers, separate from the cluster, could scan data on Amazon S3. In 2022, Google made generally available a product that carried the warehouse's storage layer out to open file formats on object storage.

Products originating from the lake side have added warehouse-like features to the lake files. In 2019, Delta Lake was released as a storage layer that brought ACID transactions and snapshot isolation to data lakes. In 2020, Databricks named the resulting shape lakehouse.

Between 2025 and 2026, the external layer started moving back inward on the Amazon Redshift side. In November 2025, Amazon Redshift enabled writing to Apache Iceberg tables. In May 2026, an instance type arrived that processes data lake queries on the cluster's own nodes. The announcement states that this removes the need for Redshift Spectrum's separate scanning fleet. What was moved outward in April 2017 came back inside in May 2026.

⚠ This does not mean that separation is over. What was separated were compute and storage, and what moved back in by May 2026 was the compute resources used to scan data from the lake. Current documentation states that on RG provisioned clusters, data lake queries run on the cluster's own compute resources, sharing those resources with other workloads. That sentence states where the work of Redshift Spectrum goes; it does not state how compute and storage are divided. Once the object of the separation is distinguished, the two statements sit together without conflict.

What This Article Leaves to Other Articles

This article is a timeline of a category. Each of the following belongs to the article named beside it.

Three Words That Mean Two Things in This Article

Three words in this article carry the same spelling for two different things.

The first is warehouse. In this article's own prose, data warehouse is the name of a category, while Snowflake's virtual warehouse is a unit of compute resources. The Snowflake page Snowflake key concepts and architecture defines it as A virtual warehouse is a cluster of compute resources in Snowflake. The paper calls the layer that does the computing Virtual Warehouses.

The second is catalog. In Apache Iceberg, a catalog is the mechanism that resolves where a table lives, while a catalog that appears in a vendor's product name refers to that vendor's own implementation. This article writes vendor catalogs by their full product names, and uses the bare word only for the Apache Iceberg concept.

The third is lakehouse. In this article's own prose it is the name of an architecture, the one the CIDR 2021 paper defines. Since April 20, 2026, Lakehouse with a capital L is also the product name Google gave to what used to be called BigLake. The two are written here as the primary sources write them, so the capital letter is the only thing that separates them.

One more note: Amazon Redshift Serverless is a product name. This article does not use serverless as an adjective in its own prose. The rule the three articles in this series share is narrower than that: each uses the word only for what its own primary source applies it to. The AWS documentation calls AWS Glue and Amazon Athena serverless, so those two timelines carry the word as an adjective. No primary source applies it to the cloud data warehouse as a category, so this article does not.

Frequently Asked Questions about Cloud Data Warehouse History

Which cloud data warehouse came first?

This article does not answer that question. It is not possible to prove from primary sources that a product was the first. What can be established is only the dates stated in each company's own primary sources. BigQuery was announced as a preview for a limited number of developers on May 19, 2010, and became generally available on May 1, 2012. Amazon Redshift was announced as a limited preview on November 28, 2012, and became generally available on February 15, 2013. According to Snowflake's own paper, Snowflake has been generally available since June 2015.

When did the separation of storage and compute happen, and who started it?

It was not a single event. Four companies arrived there in different years and in different ways, and both the words they use and the kind of document those words sit in differ. Snowflake, in a 2016 paper, wrote Snowflake separates storage and compute, and uses the same phrasing in its current documentation. Google uses the noun form, BigQuery's separation of compute and storage layers. The AWS service documentation carries no noun separation; it states the result, as scaling and paying for compute and managed storage independently, and titles one section Understanding how RG and RA3 nodes separate compute and storage. The verb decouple appears in the AWS Well-Architected Analytics Lens. Databricks writes about placing warehouse behavior on top of the lake rather than splitting anything. The four did not make the same declaration in the same words.

Who defined the word lakehouse, and where?

In the range of primary sources this article checked, Databricks is the party that defined the word lakehouse. The article of January 30, 2020 described it as combines the best elements of data lakes and data warehouses, and a paper presented at CIDR 2021 gave the definition. That definition reads a data management system based on low-cost and directly-accessible storage that also provides traditional analytical DBMS management and performance features. This article focuses on identifying where the term was defined, and does not address whether that definition is accurate.

When did Apache Iceberg become common ground across vendors?

The phrase common ground cannot be confirmed from primary sources. What can be verified is that Apache Iceberg entered the Apache Incubator on November 16, 2018, and graduated on May 20, 2020. Between 2023 and 2026, all four companies announced support for it. What that support covers, however, is not the same from one to the next. Snowflake states that version 3 of the table specification reached public preview on March 4, 2026. There are also cases where the availability status differs between reading and writing.

Is Amazon Redshift Spectrum still needed?

It depends on the configuration. The announcement of May 12, 2026 states that RG instances process Apache Iceberg and Parquet on the cluster's nodes, and that this removes the need for Redshift Spectrum's separate scanning fleet. However, current documentation indicates that data lake queries run on Redshift Spectrum when using DC2 and RA3 provisioned clusters, and states On RG provisioned clusters, data lake queries run on the cluster's own compute resources and share those resources with other workloads. Redshift Spectrum as seen from Amazon Athena is covered by a separate article.

Is BigLake still the right name to use?

The current name is Lakehouse. Google's documentation states As of April 20th, 2026, BigLake is now called Lakehouse. BigLake metastore is now called the Lakehouse runtime catalog. Configurations that span multiple clouds are referred to as borderless Lakehouse. ⚠ The general availability announcement of July 27, 2022 still carries the old name, so the names do not line up when reading older articles and announcements.

Why does this timeline not include Azure Synapse Analytics?

An earlier article already carries those dates as rows of its own. The Microsoft Azure History and Timeline includes the announcement and general availability of Azure Synapse Analytics, as well as the preview and general availability of Microsoft Fabric, all as rows with dates of their own. If this article carried the same rows, it would be a degraded copy of that article. In the range this article checked, there has been no announcement regarding the complete end-of-life for Azure Synapse Analytics.

Summary

This article sets out the history of the cloud data warehouse as a category in a timeline, and states where the category stands today.

At the core of this category lies a single question: how should computation and data storage be separated? Four companies have answered this question in different years and in different ways. The terminology they used, and the types of documents in which they expressed their answers, also varied. Snowflake uses the verb separates in the paper and in the current documentation alike, while placing a section on the same page that describes the architecture as a hybrid. Google uses the noun form and also names it as the reason a feature that reaches another cloud can work. The AWS service documentation carries no noun separation; it states the result, that compute and managed storage scale and are paid for independently, and titles one section with the verb separate. The verb decouple sits in the design guidance. Databricks writes about placing warehouse behavior on top of the lake rather than splitting anything.

Later arrivals could take earlier work as given. The cloud warehouses inherited columnar storage and single-query parallelism from papers published before the cloud, and the vendors that adopted Apache Iceberg from 2023 onward took up a table format that had already left one company's product. That relationship is not visible in a table that compares features at one point in time. It becomes visible when the answers are laid out in the order they arrived.

Between 2018 and 2020, open table formats moved outside a single company's product. Apache Iceberg became an Apache project, and Delta Lake was open-sourced. In 2023 a different answer arrived: rather than settling on one format, let one body of data be read as several formats. In 2024, Snowflake, Databricks, and Google each shipped an Apache Iceberg table or a catalog, and in 2026 the catalog side became an Apache project as well.

And in 2026, what had been moved outward started coming back inside. A data lake scanning process, moved out to a separate fleet on April 19, 2017, came back to the cluster's own compute resources on May 12, 2026. Once the object of the separation is distinguished, the two statements sit together without conflict.

This article's timeline includes rows with varying degrees of date accuracy. Rows referencing primary sources that only specify a month are presented with that level of precision. Furthermore, there are instances where dates differ between primary sources, and the article notes which date was chosen for each row. Information that could not be verified through primary sources is not included, rather than being presented with weakened claims. The founding year of Teradata is an example of this.

This category continues to evolve, and this article will be updated to reflect those changes.

Additional timelines exist for AWS services and related topics:



References:
Tech Blog with curated related content

Written by Hidekazu Konishi