What Goes Around Comes Around... And Around... - Andy Pavlo (Dijkstra Award 2024)

Today I'm going to talk about a trend or cycle that we've seen in the database marketplace and database industry over the last couple of decades. It seems that every so often, people come along and say they have a brand new database technology, a brand new way to think about how to store data. What they don't realize is that they are essentially rediscovering and reinventing concepts that have been invented in the past but had been discarded due to poor ideas. Then, those ideas come back around, and we realize, "Oh yeah, it was a mistake," and this cycle just keeps repeating itself. Specifically, I'm going to discuss how people reinvent data models for databases and why we keep seeing this pattern of making the same mistakes over and over again. So, first, what is a data model? For this audience, I don't think I need to define it in detail, but essentially, it is the way you express or represent how data is going to be stored, accessed, and manipulated within a conceptual framework in a database system.

You think of it as a high-level abstraction of how we're going to represent data in a database. I'm going to argue, and for this audience, it should not be controversial, that the relational model, in combination with a declarative language like SQL, should be the default choice for anyone building a new application today. It has basically dominated the database market since the 1980s. However, the problem is that, every 10 years, someone comes along and says the relational model is outdated and SQL is too slow. They propose a better way of doing things and suggest we throw away everything we've done in the past.

Let's switch over to that. The current trend you see right now is people claiming that generative AI with large language models (LLMs) is going to replace SQL. You can find tweets from this individual who builds Vespa. I believe he's either Swedish or Finnish. He essentially says, "Oh yeah, SQL's dead, SQL's wrong; you should be querying your database with natural language."

You go even further; this guy basically says SQL is going to die at the hands of AI. And of course, he's selling a video about how to use LLMs to query your database, right? But again, this is representative of an overall trend where people keep saying SQL should be dying and that we have a better way to do this. So what is the cycle? What does it look like?

So you start from the very beginning. People are like, "Oh, SQL is great! Fantastic! This is the way we should be accessing our database." But then there’s some change in applications, a change in the workload, or the operating environment—like the advent of the cloud—and people say, "Oh, no, no, no, SQL is bad!" You can replace "bad" with your favorite adjective, right? SQL is slow, old, awkward, inconsistent, not web-scale, whatever it may be.

The new thing I found this year is that SQL is evil. It involves stealing people's identities and front-loading the machines with the SQL database. Right? So SQL is going to help you steal elections. Actually, it involves front-loading the machines with the SQL database.

Right? So, SQL's going to help you steal elections. Actually, if you go back, my favorite one is the woman in the corner, right? So this guy's ranting. The player doesn't know what he's talking about.

Fraud involves stealing people's identities and front-loading the machines with the SQL database. She is the only one not standing in front of the American flag, right? So, what happens next? Well, people say, "Alright, SQL is stupid; SQL is bad. Let's build a new system." All the venture capitalists come around and start throwing money at these new startups that are trying to replace relational databases with SQL. Alright?

And then what happens next is that people realize, "Oh, well, a lot of the promises that these new systems are making turn out not to come to fruition when you actually try to build real applications with these things." Then SQL basically says, "Oh, yeah, there are some good ideas in these new products and systems. Let's expand the relational model and expand the SQL standard to include them." And then you're back where you started—in the beginning—saying SQL is great. This happens over and over and over again.

And so I'm not the first person to recognize this pattern. There was a very famous paper by Mike Stonebraker in 2005-2006 called "What Goes Around Comes Around," where he went through the history of data models and databases since the 1960s. He discussed how all these additional data models were inferior to the relational model. You can think of it as before and after times—there's BCE (Before the Relational model or Before the COD era). All these earlier models were hierarchical, like IMS and network storage or data models.

All these were the early prototypes. The relational model truly nailed it from the very beginning, and everything else is just a bastardization of this. He would claim that the object-relational model from Postgres is the dominant one because it's extensible, but I would just categorize that as part of the relational model, since you can extend it further now. Mike and I wrote a paper that was published this year, titled "What Goes Around Comes Around." In this paper, we examined the last 20 years since he wrote his paper in 2005-2006, focusing on all the data models that have emerged since then.

So this talk is basically going to go through all these different data models and explain why, once again, they are inferior to the relational model in SQL. I will try to limit my discussion to just the data models and the query languages, but there will be certain times when I have to talk about the implementations, because the implementations themselves are going to be inferior to what already exists in relational systems. So if you fall asleep and don't care about the rest of this talk, the main takeaway is that the relational model and SQL still remain the best choice for building new applications today. There will be one data model in particular that I will mention at the end, where the relational model may not make sense, and you may want to use a specialized system specifically for it. So we are going to go through these one by one, and we'll discuss why the relational model still remains the champion today.

Alright, so let's start with the simplest data model you can have: a key-value store. It's just an associative array that maps a key to a value. The value is typically stored as a byte array; the database system doesn't know anything about the contents inside of it. It just sees this blob of data and doesn't know if you're storing JSON or an image. It simply knows how to give you back the value when you ask for it.

And so there are essentially two categories of key-value store systems. The first one would be distributed key-value stores, such as Memcached, Aerospike, and at least the early version of Amazon DynamoDB. These are shared-nothing systems that can scale out and store data very quickly. However, they don't have many of the features you would expect in a fully featured database system. You can't inspect the values, and you can't use secondary indexes. They forgo a number of these additional features to ensure reliable and scalable performance.

The other category will be embedded storage managers, or embedded key-value stores, such as RocksDB or LevelDB. These are libraries that you can embed into a larger application or system, providing you with transactional or reliable storage, allowing you to build an interface on top of it. These tools are excellent for getting something off the ground quickly. Additionally, if you are storing caching data or session data and do not have significant querying needs, then using something like Memcached would be fantastic, as it can scale effectively for you.

But the problem that you often see is that people start off using these key-value stores, and then over time they realize, "Oh, maybe I do care about what I'm actually storing in the value," because they want secondary indexes or they want to start doing aggregations. As a result, they essentially have to write a lot of this code in their application. What has happened over time is that the distributed key-value stores realized that people wanted additional features in their database systems, so they had to expand the data model to not just store opaque values, but actually store JSON or something more structured. I would argue that you're better off starting with a relational database system, even if you just need key-value capabilities in the beginning, because that's just a table with two columns. As your application's needs expand over time, you have SQL right there, allowing you to keep using that without having to migrate your data anywhere else. So, again, for simple tasks like caching, a distributed key-value store is a good idea.

But anything more complex than that, you probably want something else. Now there's another trend where you use, again, these embedded key-value stores as the underlying storage layer or storage manager to build a larger system around it. For example, CockroachDB started off using RocksDB as the storage manager. I think that's fine; it's not clear what the performance overhead is if you use a separate storage manager instead of integrating everything yourself. However, it gets you up and running pretty quickly, and I think there's a positive side to that.

So then we get to the MapReduce systems. MapReduce is a programming paradigm; it wasn't exactly a data model, as it was primarily focused on storing rows and processing them. This concept was invented by Google in 2004-2005 as a distributed storage and processing system to build their index for Google Search. The data model is defined by the programs, specifically the Map and Reduce programs that you will run.

It isn't something you define a schema like you normally would in a relational data system. You have to write the code to process the data to understand what the schema inherently is. Google wrote the first paper in 2004 or 2005, and then there were a bunch of clones that came along a few years later, basically trying to recreate the thing but make it open source. The most famous one was from Apache, but there were proprietary implementations from Hortonworks and MapR as well. I was sort of involved in this controversy at the time, around 2008 or 2009, when essentially all the MapReduce proponents were arguing that you didn't need a relational database or SQL.

If you want to start doing things on a large scale, you should consider using one of these MapReduce systems. There were a pair of papers published by the inventors of MapReduce at Google, Jeff Dean and Sanjay Ghemawat, as well as a paper that I co-authored with Stonebraker and DeWitt. This work essentially argued that MapReduce was misguided; it was like reinventing parallel databases from the 1980s and 1990s. We argued that users should use SQL and a declarative language, and that the approach they were taking was fundamentally flawed. Well, it turns out we were correct, and people eventually rediscovered that having a declarative language, like SQL, is beneficial. Embedding the schema and data model in procedural code is actually not a good idea. In an effort to remain relevant and provide SQL capabilities to their users, all the Hadoop vendors and MapReduce vendors grafted a SQL layer on top of their systems. They would take your SQL query, convert it into a MapReduce program, and then execute that program.

Right? It turns out that's a bad idea too, because now you have this extra step, and the MapReduce programming paradigm is just way more inefficient than how you would do a distributed database. Again, these things were invented in the '80s and '90s. Then the Hadoop market crashed. Cloudera did go public, but eventually, they went back to private equity and are barely hanging on. MapR is dead, and Hortonworks merged with Cloudera. Hadoop really isn't seen as a leading technology anymore. For the young people in the audience, you may not realize this, but this is what Marcin is famous for. He's the one who contributed to the decline of these companies with Snowflake. People then realized, "Oh, I want SQL." Carlsson is also famous for this, right? He's the one who helped kill off those companies with Snowflake as well.

And people didn't realize, "Oh, I want a sequel. I want something like Snowflake." Google even announced that they were going to drop MapReduce internally in 2014 because, again, it was this sort of batch programming paradigm that wasn't scalable for what they needed. So, it's not to say that there were all bad ideas in the MapReduce world. The idea of HDFS, like a cheap distributed pen-only file system, that's what S3 basically is today. So the idea that you're going to separate compute from storage to do large-scale data processing is something that we actually got from the MapReduce world, and then Marcin went to town with it. There are other aspects of MapReduce that also came along as well.

Again, there is the idea of having a shuffle phase, which is prominent in BigQuery. This is where we've expanded our approach, not so much in SQL or the relational model, but by adding features to the implementations of SQL-based systems. Next, we have document databases, sometimes referred to as JSON databases. Here, data is represented as JSON, which consists of hierarchical data structures. In these structures, you have key-value pairs, and the values themselves can be scalar values, arrays, or other nested documents.

These systems are loosely categorized under a trend from the late 2000s to the early 2010s known as NoSQL. When people think of NoSQL, they often associate it with document databases, but the term is somewhat misleading as it encompasses other types of databases, such as key-value stores. Probably the most famous of these is MongoDB, which is still in use today. What's interesting about the NoSQL trend is that it defines a system more by what it lacks rather than by its features. For example, it often emphasizes that it does not use SQL and might also exclude features like transactions or joins. Ultimately, these databases are primarily document databases or JSON databases.

And so, all the proponents of these systems didn't realize that they were making the same arguments as the XML databases from the 1990s, and prior to that, the object-oriented databases in the 1980s. Again, there are a bunch of these companies you've probably never heard of, like Versant, O2, and ObjectStore. As far as I know, these companies are defunct, but they were making the same claims that all the JSON databases are making today. One of the core things they discussed, in addition to not supporting SQL, is the idea of denormalizing your data or pre-joining it. For web applications, if you want to retrieve Andy's records in a specific order, rather than making multiple queries to get that data or doing complex joins, you simply embed everything into a single JSON document. This way, when you fetch it, you bring everything you need all at once.

Well, it turns out that, again, SQL was a good idea, and all the major NoSQL databases have essentially relearned the lessons from the 1970s and have added SQL back. However, they don’t call it SQL for some reason. Instead, they claim that they're inspired by SQL; they always have names like PartQL or CQL. So, they each have their proprietary version of SQL, but for all intents and purposes, it’s basically SQL. They have essentially exposed a relational database interface to you.

And even the number one standout, the one system that you thought would never support SQL, I actually went to visit them in 2015. I remember speaking with the CTO, the co-founder, and he said, "You'll never see us support SQL, mark my word." Well, that person left the company, and soon MongoDB added support for SQL. They also realized that having schemas is a good idea and that having integrity constraints is important, which again is the bedrock of the relational model proposed by Ted Codd in the 1970s. It turns out transactions were a good idea too. Even Google came around and said, "Oh yeah, we want transactions," and they built it into Spanner. The idea that you're going to separate the logical and the physical data representation turned out to be a good idea as well.

So, SQL expanded. As I said, Siegel realized, "Oh yeah, people want to write applications using JSON." Basically, it became the de facto standard for how to transfer data back and forth between applications and web services. In 2016, they added JSON operators. In 2023, the standard added JSON types. However, PostgreSQL, Oracle, and a bunch of other systems have had these features for over a decade now.

And so what you're seeing now is that the intellectual distance between a document database, like MongoDB or Cassandra, and a relational database, like PostgreSQL, is getting blurred. The lines are becoming indistinct. For example, the relational database can sort JSON, and the JSON database can handle relational data. I think that in a short amount of time, they will essentially become one and the same. It will be somewhat strange to refer to it as a NoSQL system when all these systems are essentially handling SQL operations.

The next category, or data model, is column family or wide column. This is essentially similar to a document database; the only difference is that it has only one level of nesting instead of arbitrary nesting. Several systems emerged, claiming that column family was a whole new paradigm and a new way of representing data, largely inspired by a paper that Google wrote on a system called Bigtable. HBase, Cassandra, and SolidDB are essentially doing the same thing.

We would not be discussing this at all if it weren't for Google, right? People saw the Google paper and thought, "Oh, Google is making a lot of money. Column families are the way to go. Let's build our system on that." However, they didn't realize they were simply reinventing and replicating what the document database developers were already doing.

Again, even Google came out with Bigtable, and this year, Bigtable now supports SQL. Even though they were one of the first NoSQL systems, Google now supports SQL in it, right? Because, again, it's a good idea. So there's not much more to say about this, other than it’s all the same arguments we made about document databases. Integrating streams, transactions, SQL, and declared query languages—these are all good ideas. All right, then we get to the graph databases.

With graph databases, the idea is that you're representing a multi-graph structure that supports key-value labels for nodes and pairs. Essentially, you have nodes and edges between them. There are two categories of graph databases: RDF and property graphs. RDF is a subset of property graphs, so we'll focus on that one.

Probably the most famous one is Neo4j. It's been around for a long time, but there are many other graph databases that have emerged as well. Again, you're seeing the same argument: if your application looks like a graph, you should use one of these specialized graph databases. Don't put it into a relational database, as performing joins and traversing graph structures can be inefficient. I would argue that the graph model is essentially the same as the network model invented by Codasyl back in the 1970s.

So, all the same problems that people have with codicils—where you're writing algorithms and your queries and your application code to traverse the graph and find the thing you're looking for—all of that is a bad idea. Additionally, there have been advancements in how to run queries on relational databases, which means you don't even need specialized systems. The key advantage that specialized graph databases offer is that, when you run a graph traversal, you can do that all on the server side. However, before the additional modifications to SQL, you basically had to make multiple round trips back and forth between the application and the database as you conducted the traversal. Fortunately, there are now several improvements that can significantly speed up this process. With Peter Bons being here, the SQL 2023 standard introduced SQL PGQ queries, which were heavily advocated by Oracle as well.

And so now you understand that within SQL and the relational model, the relational model has expanded to add support for graph databases or graph-like queries. But why would you even need to use one of these specialized systems? I always like to show this paper by Peter and the team at CWI, where they demonstrate that with some changes to DuckDB, at least in an earlier version, it can outperform Neo4j, the leading graph database, by 10 times, without even implementing all the additional optimizations that I have mentioned. People often ask me if graph databases and graph models are so different from the relational model that one should never use a relational database and must instead rely on these specialized systems.

Peter's paper and other research show that you don't. I even publicly state all the time that graph databases are not going to be around or are not going to be a big deal. There was some guy on Hacker News who said, "Oh, graph databases are going to overtake relational databases in 10 years." I basically responded with a public bet: by the end of 2030, if graph databases surpass relational databases in market size, I will wear a shirt for the rest of my life that says, "I love graph databases." So far, it’s 2024, and I’m still doing okay.

All right, so then we get to tech search engines. These are kind of interesting because they take unstructured data, documents, text, PDFs, and other formats. You are essentially trying to extract structure from this data so that you can run queries to find specific information. There isn't really an inherent data model because, again, text is unstructured. There is no data model.

But again, it's the idea of extracting things out—the tokens—and then building indexes on top of that to find the things you're looking for. The core tenets of a tech search engine go back to a project called SMART from Cornell in 1965. There have been numerous systems since then that borrow many of the same ideas. There are a lot of products in this space; probably the most famous one is the full-text search index called Lucene. Additionally, there are several systems built on top of it, like Elasticsearch and Solr, which expose a non-SQL interface to allow lookups on text data. These are very common and are often used because the challenge in relational databases is not that they can't build a text search index; it's that the SQL standard is not widely adopted by anyone using these systems, so all the syntax is completely different.

So again, all the leading relational database systems will have full-text search indexes, but people don't use them, not because the data model is wrong, but because the interface and the libraries that use them are not as good; they are not as robust as the specialized systems. I would argue that having to maintain a separate database system just to perform text searches from the main database is a bad idea, but people still do it. I don't see that changing anytime soon. Now, one thing that is changing in full-text search is that people no longer want to perform exact searches, such as looking for keys or certain words. Now, they want to start doing searches based on the meaning or the semantic understanding of the data, and this is where vector databases come into play. However, before we can talk about vector databases, we first need to understand the more general case of array databases, right?

So, vectors are just one-dimensional arrays, matrices are two-dimensional, and tensors are three-dimensional and more, right? There are several systems that are specialized to store our matrix data and array data. Additionally, there are various tricks you have to employ when the structures don't align perfectly, or when dealing with sparse or dense matrices. While there aren't many systems in this space and the market isn't large, I would argue that this category of database systems is one where you may not want to store data in a relational system. Simply using a row-store or column-store architecture might not be sufficient because the way you want to traverse arrays may not always align with columns or rows. It may involve a more complicated path through the data. Among these systems, Rasterman is probably the one that has been around the longest. There has been a significant effort to build an open-source matrix database or array database called SciDB, which has largely fizzled out over time. Additionally, there is a commercial system called TileDB, but they prefer to present it with a relational interface rather than emphasizing its identity as an array database.

As I said, you probably don't want to store arrays or matrices in a relational database system, and if anything, it actually goes against what Ted Codd originally proposed in his paper on the relational model back in the 1970s. As he stated, the values always had to be scalar; you couldn't have arrays, you couldn't have matrices, and you couldn't have nested data. Of course, he's no longer alive, and the relational model has expanded. So in 2023, support for multi-dimensional arrays has been added. Again, I don't think you want to do this in PostgreSQL; you would want a specialized engine. However, now at least in SQL itself, through the SQL interface, you can perform traversals and lookups on these arrays.

So, I think that's a good idea, but you might still want to build a specialized system or a specialized execution engine to process those queries more efficiently. We'll see how that goes over time. Of course, now the hottest thing is vector databases. This is where all the money is being invested in new startups. All the people I showed at the beginning, claiming that SQL is going to die at the hands of generative AI, are all building vector databases. Vectors are essentially a one-dimensional array that acts as a document store, where you have some kind of JSON data, and then you're going to have one or more vectors that correspond to these embeddings, representing some semantic meaning about the data. So again, there's a lot of data in this space.

The four that are probably the most popular are Pinecone, Weaviate (which I believe has its headquarters here in Amsterdam), Milvus, and Quadrant. The key distinction they have from traditional text search indexes and relational systems is their support for approximate nearest neighbor search. This is essential for finding items that are similar to your input. You want to be able to provide your vector, or all your vector embeddings for your data. When you perform a query and conduct a lookup, you generate a new embedding for your query and find the vectors in your dataset that are closest to that.

And somehow, they magically match up, suggesting that there's something implicit within the vector. When you find vectors that are similar to you, they share the same semantics—the matching semantics. I would argue, and I have claimed this publicly, that the vector data model and vector database are not a substantial deviation from existing systems and models. Even though this has required you to invest a significant amount of money in new startups to build brand-new systems, one thing vector databases do better than existing relational systems is their superior integration with the toolkits and frameworks that people are using to build retrieval-augmented generation (RAG) and generative AI applications. They can integrate more effectively with OpenAI natively within the database system.

Now Postgres, Oracle, and others are trying to improve their capabilities, but one of the things that vector databases have done really well right out of the box is support for vector indexes. This is not a deep prediction, but it's clear that every major database system, every major relational data system, will have some support for vector indexes in a short amount of time. What's fascinating about this is that when you look at JSON, it was a hot topic when MongoDB was released in 2007-2008, but it took about four or five years for relational databases to add support for JSON. The SQL standard didn't incorporate it until 2016. However, the time it took for these developments pales in comparison to the current demand for semantic search on vectors, especially with the rise of tools like ChatGPT becoming a household name.

By the time you took from that, it became conventional wisdom that you want to have support for this. All the major relational database systems added support for vector searches within a year. There are many blog articles from various database systems announcing that they will implement their own vector search. For example, Oracle even announced they were going to have one, and theirs came out later this year. In my mind, the idea that all these existing relational database systems could add support for vector searches or some similarity search in such a short amount of time—once this became a desired feature—suggests that it's not a major paradigm shift in how you want to store data.

It's just adding a new index, adding a new data type, and adding a new execution and lookup to our operators. It doesn't require a complete rethinking or throwing away what already exists in relational systems. I'm not naive enough to think that the relational model is perfect. One of the things that, at least in the case of document stores, that they got right is that the out-of-the-box experience is fantastic. If you've ever used MongoDB, you turn it on, start throwing JSON data in, and you don't have to declare a schema. You don't have to worry about integrity constraints.

You just start throwing things in. Of course, that's great to get up and running. Long term, you're going to have problems, right? Because now your data is going to be really dirty. But getting up and running is important for a lot of applications. Pandas and Jupyter notebooks do a good job of this as well. So, I would argue that relational systems should do whatever they can to make it easier to start processing, analyzing, and storing data very quickly.

One of the things that DuckDB does fantastically well is that you can turn it on, input your FROM clause with a CSV file, and it will read and start processing right away. It's not easy to do that in Postgres, SQLite, and MySQL. You have to set things up ahead of time or obtain the right permissions. So, getting started within the first five minutes for people using these systems is really important, and I think relational systems could learn from that. I'm also not naive enough to think that SQL is perfect, right?

So the problems of SQL have been well-known since the 1980s, right? There's a famous book by C. J. Date and Hugh Darwen called "The Third Manifesto," where they basically declare all the issues that SQL has. Now, they're claiming that a lot of the problems stem from SQL deviating from the true vision of the relational model established in the 1970s, but there are other issues as well. I would argue that the problem of replacing SQL is not a technical one; we could certainly come up with a better language. The significant inertia behind SQL comes not just from the ecosystem, but also from the knowledge of it and the tools available.

It's really, really hard to overcome that. It's not the 1980s anymore, where we have a juggernaut or a behemoth like IBM that can come down from the mountain and say, "Okay, this is what the language is going to be," and everyone just follows them. The closest you can get is Google coming along and saying, "Here's our Google SQL standard," but nobody actually ended up using it. The fact of the matter is that the SQL standard now basically revolves around PostgreSQL, because people take the PostgreSQL parser and reuse that, allowing the system to get up and running very quickly. However, again, no one follows that exactly. There are some people in the room here who have tried to write better versions of this. This is a paper from CIDER by Thomas Neumann and Viktor Leis.

This thing says, "Segal sucks; here's a better version of it." Google released their version of something similar with pipes this year. But again, these are proposals. It will be very hard to overcome the SQL inertia. A survey was conducted this year. I know the video we watched earlier said Python is the most popular programming language in the world.

There was a survey among students about which language they think they need to know for their future careers, and SQL ranks number one over Python, right? Yeah, so SQL is not going away. We kind of have to live with it, and we can try to hide things in front of it, but it's going to evolve over time. Alright, so going back to this chart here, where are we in the cycle for some of the examples that I talked about before?

So, MapReduce is dead; it's not really a thing anymore. Key-value stores are a sort of separate category. However, I would place document databases right here. The document database community has realized that SQL is actually a good idea. Almost all document databases now support SQL, including MongoDB. Essentially, relational databases now appear very similar to them.

Peter Bontz is, basically, unaware that we shot him in the kneecap. He said that graph databases are stupid and that SQL can support these functionalities. Those aren't my words, but I believe that eventually, all databases will need to support SQL or risk becoming obsolete in a short amount of time.

Vector databases are down here. There's still a lot of money being thrown at them because it's the hot thing. General AI is the hot thing. However, over time, I think they're going to transition in two ways. One is that they are going to ask for SQL and basically look like a database system.

But now, again, we face the same problem as with document databases, where they will basically be indistinguishable. Alternatively, they might adopt the Elasticsearch, text search route, which does not support SQL or relational databases, meaning they won't become the database of record. Instead, they will always serve as this sort of side cache that you can query separately for certain purposes. So now, what the next development will be, I don't know; it depends on what emerges in the application landscape. However, I guarantee you that by 2030, there will be something else claiming that SQL is outdated, that SQL is wrong, and that relational databases are also outdated and incorrect.

We have a better way to do this; I just don't know what it is yet. So now, we're here for Marcin, and it's interesting to think about where Snowflake fits into this. As I mentioned, Snowflake basically eliminated all the MapReduce systems, right? What Snowflake got right, and what Marcin is a genius for, is that they started off with SQL from the very beginning.

So, they saw the hype surrounding MapReduce being the greatest thing, but they knew that was actually a bad idea. Rather than following the trend of transitioning from NoSQL to eventually adding SQL, they started by adding SQL from the very beginning. They found themselves in the right place at the right time when people began to say, "Okay, MapReduce is slow, MapReduce is stupid, we want a SQL interface." Voilà, Snowflake emerged. I would argue that DuckDB is the next contender in this space. Maybe in five years, we'll be giving Hannes and Mark this award. Basically, all the people doing data science locally in these Jupyter notebooks and with Pandas are realizing, "Oh, these things are kind of slow."

Having SQL is actually kind of nice. You can do some quick data processing. Oh, look, here's a relational database with SQL that I can run locally. Fantastic, DuckDB, there we go. So again, what goes around comes around. I think Snowflake was designed for large cloud systems.

SQL was a good idea, and people adopted it. DuckDB is in that same space right now. Okay, so people will continue to make the same mistakes over and over again, and I guarantee you that, in five or ten years, we'll see something equivalent to that, as people go through the same cycle. The lines are getting blurred between what's a SQL system, what's a non-SQL system, and what's nice to see is that all the new major databases that are emerging, apart from the vector database ones, are all supporting SQL out of the box.

There are a lot of Snowflake killers out there, and they're all starting off with SQL. Nobody in that space is trying to start something that's completely different. I would say that the relational model has its issues and concerns, but it is basically the fundamental way of storing data. No one is going to try to come up with a new way to do one plus one equals two.

The relational model is the bedrock we can use to build data applications and data systems. However, SQL will continue to improve over time. While it still has some unusual aspects, it should be the default choice for everyone when it comes to getting up and running quickly. With that, I'm happy to answer any questions. Thank you. Thank you.