MySQL 9.7 LTS, the MySQL Release for AI: What Actually Works

On 21 April 2026, MySQL 9.7 shipped: the first LTS since 8.4, supported until April 2031 and extended to April 2034. This is the version a project will settle on for years, and the one that will carry its artificial intelligence workloads. The question that matters is not what it announces, but what it actually allows.

Search by meaning, in one minute

A classic search compares characters. If your catalogue says "walking boot" and the customer types "hiking shoe", they find nothing, even though both describe the same product.

Vector search compares meaning. A model turns each item into a numerical fingerprint, and two contents close in meaning produce two close fingerprints, even without a single shared word. That is what lets a search engine understand a request phrased in the customer's words rather than the seller's.

Since version 9.0, MySQL can store those fingerprints. From there, things deserve a closer look.

Storing is not searching

On a MySQL you install yourself, you can record those fingerprints and read them back. You cannot compare them with one another.

The function measuring how close two contents are does exist, but the official MySQL manual is explicit: it is only available in Oracle's cloud offering. Neither the Community edition, the one almost everyone runs, nor even the paid Commercial edition includes it.

For a feature whose entire value rests on comparison, that is not a detail. It decides your hosting, and therefore your running costs for the life of the project.

What 9.7 changes, and what it does not

The real news in this release is its status, not its vectors. An LTS is a foundation a business commits to for years without the quarterly upgrade treadmill. For a project starting today it is the right target, and an easy choice to defend.

On search by meaning, however, nothing has moved between 9.0 and 9.7. Nothing was added to the free edition in three years. The comparison function is still missing, and so is the optimisation that would make searching a large volume fast: without it, every search walks through every row. On a thousand products that is painless, on a million it is another story.

The three workable paths

Change the server without changing the database. Percona ships a MySQL distribution that adds the comparison function, usable on any hosting. It is a drop-in replacement rather than a migration, and it stays open source.

Move to Oracle's cloud. This is the path the vendor intends, and it works. It means accepting the hosting and the billing that come with it: an architecture decision before a technical one.

Put a dedicated engine alongside. Keep MySQL for business data and hand search by meaning to a specialised service. More moving parts to maintain, but each part does its job, and you depend on nobody's roadmap for a central function.

And what about PostgreSQL?

The comparison is unavoidable, because it is the other open source database found on the same projects, and the answer there is very different.

PostgreSQL does not carry search by meaning in its engine: it is added by an open source extension, pgvector, whose current version shipped on 1 October 2026. And that extension does what the free edition of MySQL does not: compare two pieces of content, and search a large volume quickly thanks to indexes designed for it.

It is also offered as standard by most managed hosting providers, from Amazon's offerings to specialised platforms. You are locked in with nobody.

The table, without the jargon

One precaution if you go with PostgreSQL: insist on a recent version of the extension. Releases before 0.8.2 carry a vulnerability fixed since, and that is the kind of detail a host will not raise on its own.

So what do we recommend?

New project where search by meaning is central: PostgreSQL, without hesitation. The function is there, open source, mature, hostable anywhere. Choosing MySQL in that case means paying later, in forced hosting or in bolted-on parts.

Existing MySQL project where the need is secondary: do not migrate the database for this. Changing database engine is a project in its own right, with its risks and its budget. The MySQL distribution shipped by Percona adds the missing function on any hosting, and a dedicated engine alongside covers the rest. Both cost a fraction of a migration.

Existing MySQL project where the need becomes central: the migration question is legitimate. It then comes up as a costed project, with an inventory, a plan and an acceptance phase, not as a decision taken on a Friday evening.

The real criterion is not your provider's favourite database. It is whether search by meaning sits at the heart of your product or at its edge. At the heart, it justifies choosing the engine around it. At the edge, it never justifies rebuilding everything.

The question to ask before any of this

Do you need it?

On a catalogue of a few hundred items, a well-tuned classic search with synonyms and typo tolerance answers almost every case for a fraction of the complexity. Search by meaning becomes interesting when volume is large, when your customers' vocabulary does not overlap with your catalogue's, or when you need to relate content sharing no words at all.

Adding it to a site that does not need it means funding compute cost, one more dependency and a maintenance item, for a gain nobody will measure.

What we take from it

MySQL is moving towards AI, the direction is set and later versions will close the gap. But an announced feature is not an available feature, and the difference is in the manual rather than in the press release.

This is a trade-off settled at scoping rather than mid-build, because it commits hosting and running costs for years. If your project raises these questions, our IT consulting and guidance page describes how we work through them, and the work on code architecture is what lets you swap search engines later without rewriting everything.