Today: Microsoft shores up its AI strategy heading into a pivotal year, Meta is getting into the AI SaaS business with the former leader of Salesforce's AI division, and the latest enterprise funding.
Today: OpenAI would rather ChatGPT users spend more time using its tool than other "copilots," HPE rolls out a new supercomputer design, and the quote of the week.
Today: Why enterprise open-source contributors might be the secret weapon against patent trolls, AI models are starting to run into scaling problems, and the latest enterprise moves.
Google announced plans this week to bring its Gemini foundation model into its database strategy, giving administrators new tools to maximize uptime and generate SQL code.
Long before OpenAI's ChatGPT kicked off the generative AI craze, Google Cloud enjoyed an advantage among the AI curious thanks to investments in tools like BigQuery, a data warehouse that was popular even with companies that preferred to do most of their computing on AWS or Microsoft Azure. Now that every company is under pressure to articulate an AI strategy, Google announced plans this week to bring its Gemini foundation model into the heart of its database product lineup.
Andi Gutmans, vice president and general manager of database at Google, said these new Gemini-powered features will give database administrators a new set of tools to maximize uptime and write the specialized code needed to manage one of the most important parts of any company's tech stack. Users of Gemini in Databases will be able to generate SQL code with natural-language input and take advantage of an AI database-management system "that doesn't go to sleep when you go to sleep," Gutman said in an interview this week at Google Cloud Next.
Gutmans also touched on the future of vector databases and Google's decision to back Valkey, an open-source fork of Redis that arose after Redis (the company) decided to change the licensing behind its namesake project. As someone who started working on open-source software in the 1990s, Gutmans believes that source-available licenses are compatible with community-driven development philosophies but that inconsistent licensing practices erode trust.
This interview has been edited and condensed for clarity.
How will customers consume Gemini in Databases? Is that a separate service or kind of a layer on top?
Gemini in Databases is really consumed across the database portfolio. It's basically an option that you turn on and then you get access to Database Center, which allows you to manage all your whole database state. Right now we support Cloud SQL and Alloy DB as part of that. But what you're going to see in the coming months is other databases also being supported, which is very important for us to complete that.
One of the big benefits of Gemini in Databases is that it watches your whole database's state for you; not just point databases, but [it] actually can make sure that all your databases are backed up, everything is secure, if you have performance issues calling those out. We're very excited about it, because it's not only a proactive question and answering experience, this system doesn't go to sleep when you go to sleep and can also make recommendations as it's watching your systems that can give you feedback.
Are coding assistants for databases the same as other coding assistants that we've seen that help people write code in a variety of different languages? Or is there something unique to generating that type of code in this type of environment that requires a different approach?
There were two different code generation announcements we made yesterday. One was in Gemini in Databases: This system, which is in Database Studio, which really helps developers move from natural language to SQL. The other one was in AlloyDB AI, where we said we're going to have a natural language interface for developers, meaning developers get an API as they're building their applications.
While it's not completely different (moving) from generic natural language to SQL, what you'll find is if you just do generic natural language to SQL, your results aren't going to be that great. So what we really do is we make sure that we understand the context, we understand your metadata, and we really inject the right information to the foundation model to truly generate the SQL at a much, much higher quality.
As we think about AlloyDB and the API we're delivering, one thing is just improving the quality by being able to inject the right context into the product. But even then, a lot of questions people ask in natural language are actually ambiguous. So one of the really exciting things in AlloyDB AI is that we're also giving developers an opportunity to not only ask for the SQL, but if we believe that this is still ambiguous and we're not giving you high enough quality, we will actually ask the question that the developer can pass back to the end user to do intent clarification. And then we can get to a much higher quality.
Does that plug into Gemini Code Assist?
That is the plan. We obviously had to get to Next fast and we had all our teams had to develop things quickly, so we haven't completely integrated it yet. But definitely our plan is to work really closely with our counterparts in Code Assist, developers need both.
A lot of the innovation we're doing, we're able to upstream datasets and so on to Gemini training. This is where Google is very differentiated: Our ability to influence the full supply chain of AI and really get to great outcomes is bigger than I think our competitors' ability to do that. And so for example, if my team makes Gemini better for SQL, the Code Assist folks automatically get that.
When it comes to vector databases, do you see a role for a standalone vector database in the future? Or is this just going to get subsumed into every database?
We've obviously all seen some specialized vendors, we have our own specialized Vertex AI Vector Search and customers love it and use a lot of it. I would say in general there's not a one size fits all (approach), but I would say that our hypothesis in the database team and what we're hearing from customers is (they) really have a huge amount of operational data locked up in their operational databases. These are systems that they trust from a security, governance, data protection, availability perspective. It would be much simpler for many use cases to just have those vector capabilities in [that] database.
Vector is really not a data model, it's a data type.
I do think that you're going to see a lot of customers prefer to use it that way, as opposed to having to move data around into another system. Moving the data around is more work, it's more expensive, it's more complex.
I think it's interesting how databases have evolved, there are so many these days that do all kinds of specialized things compared to ten or 15 years ago. Why are vector databases different?
A lot of these purpose-built databases are about different data models, right? So data models could be document, relational, graph, and so on. Vector is really not a data model, it's a data type. And when you look at databases over time, a lot of these data types are just added to the databases over time with an ability to index and then query those data types.
What led to Google's decision to back Valkey? What was the process that you went through in deciding that was something you would support?
From our perspective, customers really value open source. Obviously Redis the company is open to make any decisions it wants with its IP and for its business, but we did hear from customers that they really valued the fact that this was a true open-source community. So when a set of community members got together and decided that they wanted to invest their personal time to continue to drive the open-source version, we felt that was a good cause to support. We also have one engineer on our team that is actually part of that founding community.
A lot of these moves feel to me like it's leading to a future in which the only people who will be able to afford to create open-source projects at scale are companies like Google, AWS, Microsoft, Oracle, that there's this middle tier of company that can get squeezed in that equation. If you were founding a startup right now, would you do open source?
When I worked on open source, I did it because I was excited about open source. I was excited about my code being used by a lot of people. And frankly, initially, there were no commercial aspirations, right?
I think there's lots of different business models and approaches, and they're all valid. But I think it is good for companies to be very clear and consistent. Because otherwise you lose the trust of the community.
I think that open source is just going to continue to exist. I think a lot of developers just get excited about creation and having people use it, and seeing how it morphs through community. So actually, I think, you know, I'm pretty bullish and optimistic around that.
I think there's lots of different business models and approaches, and they're all valid. But I think it is good for companies to be very clear and consistent. Because otherwise you lose the trust of the community.
If I were starting a commercial open source company, now — I'm not talking about just starting an open source project — I would really think long and hard (about) what do I want my ultimate business model to be? And then just make the decision upfront that is consistent with that.
The community will be fine either way, right? If you decide upfront to be open source, or you decide to take a less permissive license like SSPL, they'll be fine if that's how you start and you stay consistent. I think where it's been an issue is where you haven't had that consistency over time.
Despite recent challenges to their hegemony, x86 chips still power the vast majority of cloud and on-premises servers in use today. However, over all those years Intel and AMD tweaked x86 in subtle but incompatible ways to suit their own needs, and Tuesday's agreement is a promise to unify x86.
This week a U.K. regulatory agency published summaries of hearings it conducted this past July with AWS, Microsoft, and Google Their responses provide an interesting look into how the cloud providers see themselves, their competitors, and the current state of the market.
For years, Oracle tried to convince longtime database customers who wanted to shed their on-premises data centers to run those databases on Oracle's public infrastructure cloud, slamming AWS at every turn. Times have changed.
Anyscale is built around Ray, an open-source project that was designed to help AI workloads scale. But in recent years, commercial pressures have forced several companies with similar open-source origin stories to put restrictions on their projects to ward off competition.
