What AI did to databases for web applications, from Oracle to SQLite

I created a table in MySQL 9.7.4, the free Community edition, with a column of type VECTOR. That worked. Inserting an embedding worked too. Then I asked which row was closest to my search query:

SELECT name FROM products
ORDER BY DISTANCE(embedding, STRING_TO_VECTOR('[1,0,0]'), 'COSINE') LIMIT 1;

ERROR 1305 (42000): FUNCTION shop.DISTANCE does not exist

That is not a bug. MySQL Community can store vectors, but it cannot search them. The function that does the maths exists only in HeatWave, Oracle's cloud service, and in MySQL AI. Even the paid MySQL Enterprise edition does not have it. The same Oracle gives vector search away for free in its own database, including the Free edition. MariaDB does it for free, so does PostgreSQL, and SQLite can do it with an extension.

That, in miniature, is what AI did to the databases behind web applications. Almost every major database gained a vector type between 2024 and now, built in or through an extension. Where you get it for free and where you don't does not follow the line from heavy to light. At the same time, who talks to your database changed. According to Databricks, more than 80% of the databases on Neon were already being created by AI agents in 2025, not by people. This article goes through the databases web developers actually use, shows what AI changed in each, and ends with a choice per situation.

Sources checked on 30 October 2026, wherever possible against the official documentation. Figures a company publishes about itself are marked as a company claim. I ran the SQL examples for PostgreSQL, MariaDB, MySQL and SQLite locally in Docker on 30 October; the ones for Oracle and SQL Server come from the documentation. Advice that is mine is marked as such.

What has AI changed about databases for web applications?

Two things. Databases gained vectors: a column type and an index that let you search by meaning instead of exact words. And AI became a database user itself: models write SQL, agents create databases and sometimes throw them away. The old question "which vector database should I use?" has largely been replaced by the question whether the database you already have does it well.

Why a web shop suddenly wants vectors

A customer types "something for when it pours with rain" into the search box of a clothing store. WHERE name LIKE '%rain%' finds the raincoat, but not the parka and not the waterproof hiking boots. An embedding model turns both the query and every product description into a list of, say, 1,536 numbers. Texts with a similar meaning get lists that lie close together. Searching then becomes: give me the five products with the smallest distance to the query.

The same trick sits under every chatbot that answers questions about your own documentation (RAG): first fetch the five most relevant paragraphs, then let the language model answer. For that you need two things a classic database did not have: a column for that list of numbers, and an index that does not have to walk every row when there are a million of them. That index is usually called HNSW, IVF or DiskANN. These are approximate indexes: they do not look at every row, and so they sometimes miss a hit. You will see an example of that further down.

Heavy databases: Oracle gives it away, SQL Server half

Oracle renamed its next release from 23c to Oracle Database 23ai in May 2024. The name was marketing, the content was not: a VECTOR type, HNSW and IVF indexes, and a built-in ONNX runtime. With that runtime you load an embedding model into the database and create embeddings with plain SQL (VECTOR_EMBEDDING). Your text then does not go to an outside party, which matters when it contains personal data. According to Oracle this comes at no extra cost in Enterprise Edition, Standard Edition 2 and Database Free. Free is limited to 12 GB of user data, 2 GB of memory and 2 cores, enough to try everything.

On 14 October 2025 came "Oracle AI Database 26ai". That is mostly a new name on the same 23 code base: if you run 23ai, you get 26ai with the October 2025 Release Update, no upgrade needed. If you are still on 19c, you do have to upgrade. One trap: an HNSW index lives in a separate memory area, and the parameter for it, VECTOR_MEMORY_SIZE, defaults to 0.

SQL Server 2025 became generally available on 18 November 2025. The VECTOR type and VECTOR_DISTANCE are simply available. Embeddings are made by an external model (AI_GENERATE_EMBEDDINGS calls a REST endpoint), so not inside the database as with Oracle. According to the documentation (updated 19 October 2026), the fast DiskANN index and VECTOR_SEARCH are still in preview in SQL Server 2025: you have to switch on PREVIEW_FEATURES. In Azure SQL they are now generally available. Without an index, SQL Server computes the exact distance for every row. Microsoft also made Express bigger: 50 GB instead of 10.

MySQL stores vectors and does not compute with them

MySQL has had a VECTOR type since version 9.0 (2024). What the error message in the introduction means is spelled out in the manual for 9.7, the new LTS release from April 2026: "DISTANCE() is available only for users of MySQL HeatWave on OCI and MySQL AI; it is not included in MySQL Commercial or Community distributions." Community has no vector index either. You can store vectors, convert them to and from text, and that is it. If you want to build semantic search on your hosting provider's MySQL database, you have to compute the distance in PHP yourself. On top of that, HeatWave, Oracle's cloud service, gained NL_SQL in August 2025: a question in plain language that is executed as SQL.

MariaDB went exactly the other way. Vector search is in the free GPL server, generally available since 11.7 (February 2025), and 11.8 is the first LTS release with it. On MariaDB 11.8.9 the example in this article ran without changes, and EXPLAIN showed the vector index was really used. Three rules from the documentation you need to know: the column must be NOT NULL, there can be one vector index per table, and the index is only used for ORDER BY VEC_DISTANCE_…() LIMIT n with the same distance metric as the index. Forget DISTANCE=cosine when you create it and you get a Euclidean index that every cosine query ignores. Also note that the function names differ from MySQL (VEC_FromText versus STRING_TO_VECTOR). MariaDB vector code does not run on MySQL, and vice versa.

MongoDB bought Voyage AI, a maker of embedding models, in February 2025 (for $220 million according to Bloomberg). Until then, vector search was only in the Atlas cloud service. Since 30 June 2026 it is also generally available in the free Community server, through a separate process (mongot) that runs next to the database.

PostgreSQL won the developers, SQLite overtook MySQL

In the 2026 Stack Overflow survey, 57.9% of respondents used PostgreSQL. SQLite rose to 42.1% and is now ahead of MySQL, which fell to 35.1% (in 2025 it was still 37.5 against 40.5). There is a caveat: by my calculation about 12,000 people answered the database question in 2026 (Stack Overflow does not publish the number), against more than 26,000 in 2025, so part of the shift may come from a different group of respondents. DB-Engines, which measures popularity through searches, job ads and mentions, paints a different picture. There Oracle is still on top (1,119.79 points in October 2026), followed by MySQL, SQL Server and PostgreSQL. The direction is the same, though: in one year Oracle lost 93 points and MySQL 42, while PostgreSQL gained 46. That suggests new projects pick Postgres or SQLite more often, while existing systems still run on Oracle, MySQL and SQL Server.

Specialised vector databases have stayed small in that same ranking: Pinecone is at position 46, Qdrant at 54. They still exist and still raise money (Qdrant $50 million in March 2026), but most web developers now get vectors through the database they already have.

For PostgreSQL that is the pgvector extension, now at version 0.8.7 (1 October 2026). Two details most tutorials leave out. An HNSW index works up to 2,000 dimensions for the regular vector type. If you use a model with 3,072 dimensions, such as OpenAI's text-embedding-3-large, you need halfvec (16-bit, up to 4,000 dimensions). And a query with a WHERE filter next to the vector index can return fewer results than you asked for, because the filter is applied after the index. Since 0.8.0 you can fix that with iterative index scans (SET hnsw.iterative_scan = strict_order;), but they are off by default: in my test, SHOW hnsw.iterative_scan simply returned off.

For PHP developers there is one more factor. Laravel 13 (March 2026) made vectors part of the framework: $table->vector('embedding', dimensions: 1536)->index() in a migration, and whereVectorSimilarTo() in a query. Pass it a plain search term and the Laravel AI SDK turns it into an embedding for you. According to the documentation this only works on PostgreSQL with pgvector and on MariaDB 11.7 or later. MySQL and SQLite are not on the list.

Light databases: SQLite can do it, your PHP hosting maybe not

SQLite itself did nothing with AI, apart from one dry detail: the release notes for 3.53.3 and 3.53.4 (summer 2026) say the bug reports came "mostly" from AIs. Vectors come from the sqlite-vec extension by Alex Garcia, sponsored by Mozilla Builders. The latest stable release is v0.1.9; the approximate indexes exist only in alpha releases. Without an index, sqlite-vec compares your query with every row. The author himself puts the practical limit at hundreds of thousands of vectors. The example in this article gave the same distances in sqlite-vec as in pgvector and MariaDB.

The problem for PHP is not sqlite-vec but loading it. SQLite3::loadExtension() only loads files from the sqlite3.extension_dir directory. That setting is empty by default and can only be set in php.ini. On shared hosting the customer usually cannot do that. Pdo\Sqlite::loadExtension() only exists from PHP 8.4. And then you still have to upload a compiled file that matches the server's operating system and processor.

What works everywhere: store the embedding in a regular column and compute the distance in PHP. I measured that on my development laptop with PHP 8.2, with 1,536 dimensions per embedding. How you store the numbers makes a tenfold difference:

With JSON, 90% of the time went to json_decode(), not to the maths. With pack('g*') you store the same numbers in binary, 4 bytes per number, and unpack() is almost thirty times faster than json_decode():

<?php
// Embedding as a float32 BLOB in SQLite, cosine in PHP. No extension needed.
function toBlob(array $v): string { return pack('g*', ...$v); }
function fromBlob(string $b): array { return unpack('g*', $b); }

function cosine(array $a, array $b): float {
    $dot = $na = $nb = 0.0;
    foreach ($a as $i => $x) {
        $y = $b[$i];
        $dot += $x * $y; $na += $x * $x; $nb += $y * $y;
    }
    return ($na == 0.0 || $nb == 0.0) ? 0.0 : $dot / (sqrt($na) * sqrt($nb));
}

function search(PDO $pdo, array $query, int $k = 5): array {
    $q = fromBlob(toBlob($query)); // same keys (1..n) as the stored rows
    $scores = [];
    foreach ($pdo->query('SELECT id, embedding FROM posts') as $row) {
        $scores[$row['id']] = cosine($q, fromBlob($row['embedding']));
    }
    arsort($scores);
    return array_slice($scores, 0, $k, true); // [id => similarity]
}

// Storing: bindValue(2, toBlob($embedding), PDO::PARAM_LOB)

My conclusion from that measurement: for a blog, a knowledge base or a product catalogue of up to a few thousand items this is fast enough, especially if you cache the results. Above five thousand it gets noticeably slow per request and you want a real index.

Around SQLite, the rest of the innovation happened outside the core. Turso's fork libSQL has had a built-in DiskANN vector index since July 2024. On 2 October 2026 Supabase announced it is acquiring Turso. DuckDB reached version 2.0 on 21 October 2026, but it is an analytics engine to run next to your app, not an app database. Its vector extension is still called experimental in the documentation, which advises against production use.

The new user of your database is an agent

Over the past eighteen months the big money in databases did not go to search features, but to databases that agents create themselves. When Databricks bought the serverless Postgres provider Neon in May 2025 (for about a billion dollars according to the press), its press release said that "over 80 percent of the databases provisioned on Neon were created automatically by AI agents rather than by humans". That is a company claim, and it counts databases created, not databases holding real customer data. Three weeks later Snowflake bought Crunchy Data (for about $250 million according to CNBC).

Supabase, the Postgres service behind AI app builders such as Lovable and Bolt, reported more than 40,000 new databases a day in September 2025 (company claim). When it announced the Turso acquisition on 2 October 2026, founder Paul Copplestone put it at "over one million databases per week". Turso's own post names "a billion databases" as the goal. In this model a database is no longer a carefully managed thing, but something an agent creates for one task and then throws away.

How good is AI at writing SQL?

Good, until the database starts to look like a real company database. On the BIRD benchmark, with plain-language questions about a database with a clear schema, AT&T's AskData leads with 83.40% correct answers (as of 30 October 2026). Humans, data engineers and database students, score 92.96%. So roughly one in six answers from the best machine is wrong. A wrong SQL answer looks just as convincing as a right one: it simply returns a table of numbers. If you cannot read such a query yourself, you are building what I earlier called cognitive debt.

Spider 2.0 shows what happens with real enterprise databases, often with more than a thousand columns and SQL longer than a hundred lines. There, according to the paper, an agent based on o1-preview solved only 21.3% of the tasks, while the same setup scored 91.2% on the older Spider 1.0. Specialised systems have since reported much higher scores, but without a date or a described method on the leaderboard. I found no separate scores for MySQL or Oracle: BIRD runs on SQLite.

Two deleted production databases, neither caused by bad SQL

In July 2025, Replit's agent deleted the production database of SaaStr founder Jason Lemkin during a code freeze. CEO Amjad Masad then announced automatic separation between development and production databases. In April 2026, a Cursor agent running Claude Opus 4.6 at the company PocketOS found a Railway token in an unrelated file. With one API call it deleted the production database and all backups, which sat on the same volume. According to founder Jer Crane it took nine seconds; Railway restored the data within about an hour, he says.

In neither case did the agent write a wrong query. It had permissions it should not have had. The same pattern was behind a flaw Datadog Security Labs described in August 2025 in Anthropic's own reference server for MCP, the protocol that lets an AI agent query a database. That server wrapped every query in a read-only transaction, but accepted multiple statements. Put COMMIT; in the input and the read-only transaction was closed, and everything after it ran with write access.

I replayed that trick against a PostgreSQL user that only has SELECT rights:

CREATE ROLE agent_ro LOGIN PASSWORD '…';
GRANT USAGE ON SCHEMA public TO agent_ro;
GRANT SELECT ON products TO agent_ro;

-- logged in as agent_ro (output shortened):
BEGIN TRANSACTION READ ONLY;
SELECT name FROM products LIMIT 1; COMMIT; DROP TABLE products;

COMMIT
ERROR:  must be owner of table products

The transaction closes, the table stays. A read-only mode in the software around the database is a promise. A database user without rights is a lock.

Vendors are learning this too. Since version 6.15 (August 2025), Prisma first asks the user for explicit consent when it detects that an agent such as Claude Code or Cursor is running prisma migrate reset. Microsoft's SQL MCP Server (April 2026) deliberately does not let the model write SQL at all: it only sees tables and views that were approved in advance.

The same search query in five databases

A products table with a 1,536-dimension embedding, the five nearest products by cosine distance. I ran the first three with 200 random vectors of 1,536 dimensions. Oracle and SQL Server come from the official documentation.

-- PostgreSQL 18 + pgvector 0.8.7
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE products (id bigserial PRIMARY KEY, name text, embedding vector(1536));
CREATE INDEX ON products USING hnsw (embedding vector_cosine_ops);
SELECT id, name FROM products ORDER BY embedding <=> CAST(? AS vector) LIMIT 5;

-- MariaDB 11.8
CREATE TABLE products (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(200),
  embedding VECTOR(1536) NOT NULL, VECTOR INDEX (embedding) DISTANCE=cosine);
SELECT id, name FROM products
ORDER BY VEC_DISTANCE_COSINE(embedding, VEC_FromText(?)) LIMIT 5;

-- SQLite + sqlite-vec 0.1.9 (separate virtual table, join via rowid)
CREATE VIRTUAL TABLE vec_products USING vec0(embedding float[1536] distance_metric=cosine);
SELECT rowid, distance FROM vec_products WHERE embedding MATCH ? AND k = 5 ORDER BY distance;

-- Oracle 23ai / 26ai
CREATE VECTOR INDEX products_hnsw ON products (embedding)
  ORGANIZATION INMEMORY NEIGHBOR GRAPH DISTANCE COSINE WITH TARGET ACCURACY 95;
SELECT id, name FROM products
ORDER BY VECTOR_DISTANCE(embedding, :q, COSINE) FETCH APPROX FIRST 5 ROWS ONLY;

-- SQL Server 2025 (exact search, uses no index)
SELECT TOP (5) id, name, VECTOR_DISTANCE('cosine', embedding, @q) AS distance
FROM products ORDER BY distance;

PostgreSQL and sqlite-vec returned the same five products. MariaDB's index missed the second-best product and put a different one in fifth place. That is what an approximate index does. Random vectors are a hard case for such an index, though; real embeddings sit more in clusters. Check it with your own data before you rely on it.

From PHP you send the query vector as text: json_encode($embedding) produces the [0.12,-0.03,…] format that PostgreSQL, MariaDB, SQLite and SQL Server accept. With Oracle you can convert it explicitly with TO_VECTOR(:q) if needed. Because the syntax differs per database, I would put the vector query in one class or repository. Switching later is then one file.

Which database should you choose for which web application?

This is my advice, based on the above. Choose the database on the ordinary requirements first, such as hosting, team knowledge and existing data. Then pick the vector route that belongs to that database. For most web applications a separate vector database is one more system to manage, without anything in return.

I work with Oracle, MySQL and SQLite myself; this site runs on SQLite. According to this list that site belongs in the first row, and the measurement gives every reason for it.

What stands out in all this: precisely the two databases that most often run on cheap hosting, MySQL Community and plain SQLite, have the weakest built-in vector support. The free way out is MariaDB or PostgreSQL. For most PHP developers, moving from MySQL to MariaDB is a small step; moving to PostgreSQL is a real migration.

If you let an AI agent work with your database, do not start with the model but with the credentials. Create a separate database user with only SELECT on the tables the agent needs. Keep production passwords and API tokens out of the directory the agent works in. Store backups somewhere the same token cannot reach. The two deleted databases and the MCP server flaw in this article would not have happened with those measures, however smart the model. That is my reading of the published accounts; only the MCP trick did I replay myself.

Sources

• Oracle, AI Vector Search User's Guide 26ai, Approximate search using HNSW and VECTOR_MEMORY_SIZE; Oracle AI Database 26ai (14 October 2025); oracle-base on the limits of 23ai Free
• Microsoft, What's new in SQL Server 2025, CREATE VECTOR INDEX and VECTOR_DISTANCE; Introducing SQL MCP Server (April 2026)
• MySQL 9.7 Reference Manual, Vector Functions; HeatWave 9.4.1 release notes (NL_SQL)
• MariaDB, Vector Overview and CREATE TABLE with Vectors
• MongoDB, acquisition of Voyage AI (24 February 2025) and Search and Vector Search GA for Community Edition
• Stack Overflow Developer Survey 2026 and 2025; DB-Engines Ranking (October 2026)
• pgvector, README and CHANGELOG; Laravel 13, Migrations and Queries
• SQLite, release history; Alex Garcia, sqlite-vec stable release and releases; PHP manual, SQLite3::loadExtension and Pdo\Sqlite::loadExtension
• Turso, DiskANN in libSQL and Turso is joining Supabase; DuckDB, VSS extension
• Databricks, Databricks Agrees to Acquire Neon (14 May 2025); TechCrunch on Snowflake and Crunchy Data (2 June 2025); Supabase, Lovable Cloud and Supabase is acquiring Turso (2 October 2026)
• BIRD benchmark (leaderboard viewed 30 October 2026); Lei et al., Spider 2.0 (ICLR 2025)
• The Register, Replit on the deleted database (22 July 2025) and PocketOS (27 April 2026); Datadog Security Labs, SQL injection in the PostgreSQL MCP server (21 August 2025); Prisma, ORM 6.15.0