Wat AI met databases voor webapplicaties deed, van Oracle tot SQLite

Ik maakte een tabel aan in MySQL 9.7.4, de gratis Community-versie, met een kolom van het type VECTOR. Dat ging goed. Een embedding erin zetten lukte ook. Toen vroeg ik welke rij het meest op mijn zoekvraag leek:

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

Dat is geen bug. MySQL Community kan vectoren opslaan, maar niet doorzoeken. De rekenfunctie zit alleen in HeatWave, de clouddienst van Oracle, en in MySQL AI. Zelfs het betaalde MySQL Enterprise heeft hem niet. Datzelfde Oracle geeft vectorzoeken in zijn eigen database gratis weg, ook in de Free-versie. MariaDB doet het gratis, PostgreSQL ook, en SQLite kan het met een extensie.

Dat is in het klein wat AI met databases voor webapplicaties heeft gedaan. Bijna elke grote database kreeg tussen 2024 en nu een vectortype, ingebouwd of via een extensie. Waar je het gratis krijgt en waar niet, volgt niet de lijn van zwaar naar licht. Ondertussen veranderde ook wie er met je database praat. Volgens Databricks werd bij Neon in 2025 al meer dan 80% van de databases aangemaakt door AI-agents, niet door mensen. Dit artikel loopt de databases af die webontwikkelaars echt gebruiken, laat zien wat AI eraan veranderde, en eindigt met een keuze per situatie.

Bronnen gecontroleerd op 30 oktober 2026, waar mogelijk bij de officiële documentatie. Cijfers van een bedrijf over zichzelf staan als bedrijfsclaim aangegeven. De SQL-voorbeelden voor PostgreSQL, MariaDB, MySQL en SQLite heb ik op 30 oktober lokaal gedraaid in Docker; die voor Oracle en SQL Server komen uit de documentatie. Adviezen die van mij komen, staan als zodanig aangegeven.

Wat heeft AI aan databases voor webapplicaties veranderd?

Twee dingen. Databases kregen vectoren: een kolomtype en een index waarmee je zoekt op betekenis in plaats van op exacte woorden. En AI werd zelf gebruiker van databases: modellen schrijven SQL, agents maken databases aan en gooien ze soms ook weg. De oude vraag "welke vectordatabase neem ik?" is daardoor grotendeels vervangen door de vraag of de database die je al hebt het goed kan.

Waarom een webshop opeens vectoren wil

Een klant typt "iets voor als het hard regent" in het zoekveld van een kledingwinkel. WHERE name LIKE '%regen%' vindt de regenjas, maar niet de parka en niet de waterdichte wandelschoenen. Een embeddingmodel zet zowel de zoekvraag als elke productomschrijving om in een lijst van bijvoorbeeld 1.536 getallen. Teksten met een vergelijkbare betekenis krijgen lijsten die dicht bij elkaar liggen. Zoeken wordt dan: geef me de vijf producten met de kleinste afstand tot de zoekvraag.

Hetzelfde trucje zit onder elke chatbot die vragen beantwoordt over je eigen documentatie (RAG): eerst de vijf relevantste alinea's ophalen, dan pas het taalmodel laten antwoorden. Daarvoor heb je twee dingen nodig die een klassieke database niet had: een kolom voor die getallenlijst, en een index die bij een miljoen rijen niet elke rij hoeft af te gaan. Die index heet meestal HNSW, IVF of DiskANN. Het zijn benaderende indexen: ze kijken niet naar elke rij, en missen daardoor soms een treffer. Verderop zie je daar een voorbeeld van.

Zware databases: Oracle geeft het weg, SQL Server half

Oracle hernoemde zijn volgende release in mei 2024 van 23c naar Oracle Database 23ai. De naam was marketing, de inhoud niet: een VECTOR-type, HNSW- en IVF-indexen, en een ingebouwde ONNX-runtime. Met die runtime laad je een embeddingmodel ín de database en maak je embeddings met gewone SQL (VECTOR_EMBEDDING). Je tekst gaat dan niet naar een externe partij, wat telt als er persoonsgegevens in staan. Volgens Oracle zit dit zonder meerprijs in Enterprise Edition, Standard Edition 2 en Database Free. Free is beperkt tot 12 GB gebruikersdata, 2 GB geheugen en 2 cores, genoeg om alles uit te proberen.

Op 14 oktober 2025 volgde "Oracle AI Database 26ai". Dat is vooral een nieuwe naam op dezelfde 23-codebasis: wie 23ai draait, krijgt 26ai met de Release Update van oktober 2025, zonder upgrade. Wie nog op 19c zit, moet wel upgraden. Een valkuil: een HNSW-index leeft in een apart geheugengebied, en de parameter daarvoor, VECTOR_MEMORY_SIZE, staat standaard op 0.

SQL Server 2025 werd algemeen beschikbaar op 18 november 2025. Het VECTOR-type en VECTOR_DISTANCE zijn gewoon beschikbaar. Embeddings laat je maken via een extern model (AI_GENERATE_EMBEDDINGS roept een REST-endpoint aan), dus niet in de database zoals bij Oracle. De snelle DiskANN-index en VECTOR_SEARCH zijn in SQL Server 2025 volgens de documentatie (bijgewerkt 19 oktober 2026) nog preview: je moet PREVIEW_FEATURES aanzetten. In Azure SQL zijn ze inmiddels wel algemeen beschikbaar. Zonder index rekent SQL Server de afstand voor elke rij exact uit. Microsoft maakte Express tegelijk groter: 50 GB in plaats van 10.

MySQL slaat vectoren op en rekent er niet mee

MySQL heeft sinds versie 9.0 (2024) een VECTOR-type. Wat de foutmelding uit de inleiding betekent, staat letterlijk in de handleiding van 9.7, de nieuwe LTS-versie van 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." Een vectorindex heeft Community ook niet. Je kunt vectoren opslaan, omzetten van en naar tekst, en verder niets. Wie met de MySQL-database van de hostingpartij een semantische zoekfunctie wil bouwen, moet de afstand dus zelf in PHP berekenen. HeatWave, de clouddienst van Oracle, kreeg in augustus 2025 daarbovenop NL_SQL: een vraag in gewone taal die als SQL wordt uitgevoerd.

MariaDB koos precies de andere kant. Vectorzoeken zit in de gratis GPL-server, algemeen beschikbaar sinds 11.7 (februari 2025), en 11.8 is de eerste LTS-versie ermee. Op MariaDB 11.8.9 draaide het voorbeeld uit dit artikel zonder aanpassing, en EXPLAIN liet zien dat de vectorindex echt werd gebruikt. Drie regels uit de documentatie die je moet kennen: de kolom moet NOT NULL zijn, er mag één vectorindex per tabel zijn, en de index wordt alleen gebruikt bij ORDER BY VEC_DISTANCE_…() LIMIT n met dezelfde afstandsmaat als de index. Vergeet je DISTANCE=cosine bij het aanmaken, dan krijg je een euclidische index en negeert elke cosinus-query hem. Let ook op: de functienamen verschillen van MySQL (VEC_FromText tegenover STRING_TO_VECTOR). MariaDB-vectorcode draait dus niet op MySQL, en andersom.

MongoDB kocht in februari 2025 Voyage AI, een maker van embeddingmodellen (volgens Bloomberg voor $220 miljoen). Vectorzoeken zat tot dan alleen in de clouddienst Atlas. Sinds 30 juni 2026 is het ook algemeen beschikbaar in de gratis Community-server, via een apart proces (mongot) dat je naast de database draait.

PostgreSQL won de ontwikkelaars, SQLite haalde MySQL in

In de Stack Overflow-enquête van 2026 gebruikte 57,9% van de respondenten PostgreSQL. SQLite steeg naar 42,1% en staat nu boven MySQL, dat zakte naar 35,1% (in 2025 was het nog 37,5 tegen 40,5). Er zit een kanttekening bij: op de databasevraag kwamen in 2026 naar mijn berekening ongeveer 12.000 antwoorden binnen (Stack Overflow publiceert het aantal niet), tegen ruim 26.000 in 2025, dus een deel van de verschuiving kan aan een andere groep respondenten liggen. DB-Engines, dat populariteit meet aan zoekopdrachten, vacatures en vermeldingen, geeft een ander beeld. Daar staat Oracle nog bovenaan (1119,79 punten in oktober 2026), gevolgd door MySQL, SQL Server en PostgreSQL. De richting is wel dezelfde: Oracle verloor in een jaar 93 punten, MySQL 42, PostgreSQL won er 46. Dat wijst erop dat nieuwe projecten vaker Postgres of SQLite kiezen, terwijl de bestaande systemen nog op Oracle, MySQL en SQL Server draaien.

Gespecialiseerde vectordatabases zijn in diezelfde ranglijst klein gebleven: Pinecone staat op plaats 46, Qdrant op 54. Ze bestaan nog en halen nog geld op (Qdrant $50 miljoen in maart 2026), maar de meeste webontwikkelaars krijgen vectoren nu via de database die ze al hebben.

Voor PostgreSQL is dat de extensie pgvector, nu versie 0.8.7 (1 oktober 2026). Twee details die in de meeste tutorials ontbreken. Een HNSW-index werkt tot 2.000 dimensies voor het gewone vector-type. Gebruik je een model met 3.072 dimensies, zoals OpenAI's text-embedding-3-large, dan moet je naar halfvec (16-bit, tot 4.000 dimensies). En een query met een WHERE-filter naast de vectorindex kan minder resultaten teruggeven dan je vraagt, omdat het filter pas na de index wordt toegepast. Sinds 0.8.0 los je dat op met iteratieve indexscans (SET hnsw.iterative_scan = strict_order;), maar standaard staan ze uit: in mijn test gaf SHOW hnsw.iterative_scan gewoon off.

Voor PHP-ontwikkelaars telt nog iets mee. Laravel 13 (maart 2026) maakte vectoren onderdeel van het framework: $table->vector('embedding', dimensions: 1536)->index() in een migratie, en whereVectorSimilarTo() in een query. Geef je daar een gewone zoekterm mee, dan maakt de Laravel AI SDK er zelf een embedding van. Volgens de documentatie werkt dit alleen op PostgreSQL met pgvector en op MariaDB 11.7 of nieuwer. MySQL en SQLite staan er niet bij.

Lichte databases: SQLite kan het, maar je PHP-hosting misschien niet

SQLite zelf deed niets met AI, op één droog detail na: in de releasenotes van 3.53.3 en 3.53.4 (zomer 2026) staat dat de bugmeldingen "mostly" van AI's kwamen. Vectoren komen van de extensie sqlite-vec van Alex Garcia, gesponsord door Mozilla Builders. De laatste stabiele versie is v0.1.9; de benaderende indexen zitten alleen in alpha-versies. Zonder index vergelijkt sqlite-vec je zoekvraag met elke rij. De maker zelf legt de praktische grens bij honderdduizenden vectoren. Het voorbeeld uit dit artikel gaf in sqlite-vec dezelfde afstanden als in pgvector en MariaDB.

Het probleem voor PHP zit niet in sqlite-vec maar in het laden ervan. SQLite3::loadExtension() laadt alleen bestanden uit de map sqlite3.extension_dir. Die staat standaard leeg en kan alleen in php.ini worden gezet. Op shared hosting kan de klant dat meestal niet. Pdo\Sqlite::loadExtension() bestaat pas vanaf PHP 8.4. En dan moet je nog een gecompileerd bestand uploaden dat past bij het besturingssysteem en de processor van de server.

Wat wel overal werkt: de embedding opslaan in een gewone kolom en de afstand in PHP uitrekenen. Ik heb dat gemeten op mijn ontwikkellaptop met PHP 8.2, met 1.536 dimensies per embedding. Hoe je de getallen opslaat, maakt tien keer verschil:

Bij JSON ging 90% van de tijd naar json_decode(), niet naar het rekenen. Met pack('g*') sla je dezelfde getallen binair op, 4 bytes per getal, en unpack() is bijna dertig keer sneller dan json_decode():

<?php
// Embedding als float32-BLOB in SQLite, cosinus in PHP. Geen extensie nodig.
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)); // zelfde sleutels (1..n) als de opgeslagen rijen
    $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 => gelijkenis]
}

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

Mijn conclusie uit die meting: voor een blog, een kennisbank of een productcatalogus tot een paar duizend items is dit snel genoeg, zeker als je de resultaten cachet. Boven de vijfduizend wordt het merkbaar traag per verzoek en wil je een echte index.

Rond SQLite gebeurde de rest van de vernieuwing buiten de kern. Turso's fork libSQL heeft sinds juli 2024 een ingebouwde DiskANN-vectorindex. Op 2 oktober 2026 kondigde Supabase aan dat het Turso overneemt. DuckDB bereikte op 21 oktober 2026 versie 2.0, maar is een analyse-engine voor naast je app, geen app-database. De vectorextensie heet in de documentatie nog steeds experimenteel, en die raadt productiegebruik af.

De nieuwe gebruiker van je database is een agent

Het grote geld in databases ging de afgelopen achttien maanden niet naar zoekfuncties, maar naar databases die agents zelf aanmaken. Toen Databricks in mei 2025 de serverless-Postgresaanbieder Neon kocht (volgens de pers voor ongeveer een miljard dollar), stond in het persbericht dat "over 80 percent of the databases provisioned on Neon were created automatically by AI agents rather than by humans". Dat is een bedrijfsclaim, en het gaat om aangemaakte databases, niet om databases met echte klantdata. Drie weken later kocht Snowflake Crunchy Data (volgens CNBC voor ongeveer $250 miljoen).

Supabase, de Postgres-dienst achter AI-appbouwers als Lovable en Bolt, meldde in september 2025 ruim 40.000 nieuwe databases per dag (bedrijfsclaim). Bij de aankondiging van de Turso-overname, op 2 oktober 2026, was dat volgens oprichter Paul Copplestone "over one million databases per week". Turso noemt in zijn eigen bericht "a billion databases" als doel. Een database is in dit model geen zorgvuldig beheerd ding meer, maar iets wat een agent voor één taak aanmaakt en daarna weggooit.

Hoe goed schrijft AI SQL?

Goed, tot de database op een echte bedrijfsdatabase gaat lijken. Op de BIRD-benchmark, met vragen in gewone taal over een database met een duidelijk schema, staat AskData van AT&T bovenaan met 83,40% juiste antwoorden (stand 30 oktober 2026). Mensen, data-engineers en databasestudenten, halen 92,96%. Ongeveer één op de zes antwoorden van de beste machine is dus fout. Een fout SQL-antwoord ziet er net zo overtuigend uit als een goed antwoord: het geeft gewoon een tabel met getallen terug. Wie zo'n query niet zelf kan lezen, bouwt aan wat ik eerder cognitieve schuld noemde.

Spider 2.0 laat zien wat er gebeurt met echte bedrijfsdatabases, met vaak meer dan duizend kolommen en SQL van meer dan honderd regels. Daar loste een agent op basis van o1-preview volgens het onderzoek maar 21,3% van de taken op, terwijl dezelfde opzet op het oudere Spider 1.0 91,2% haalde. Sindsdien melden gespecialiseerde systemen veel hogere scores, maar zonder datum of beschreven methode op de ranglijst. Voor MySQL of Oracle heb ik geen aparte scores gevonden: BIRD draait op SQLite.

Twee gewiste productiedatabases, en geen van beide door slechte SQL

In juli 2025 wiste de agent van Replit tijdens een code freeze de productiedatabase van SaaStr-oprichter Jason Lemkin. CEO Amjad Masad kondigde daarna een automatische scheiding tussen ontwikkel- en productiedatabase aan. In april 2026 vond een Cursor-agent met Claude Opus 4.6 bij het bedrijf PocketOS een Railway-token in een ander bestand. Met één API-aanroep verwijderde hij de productiedatabase en alle back-ups, die op hetzelfde volume stonden. Volgens oprichter Jer Crane duurde dat negen seconden; Railway zette de data volgens hem binnen ongeveer een uur terug.

In beide gevallen schreef de agent geen foute query. Hij had rechten die hij niet had mogen hebben. Hetzelfde patroon zat in een lek dat Datadog Security Labs in augustus 2025 beschreef in Anthropics eigen voorbeeldserver voor MCP, het protocol waarmee een AI-agent een database kan bevragen. Die server zette elke query in een read-only transactie, maar accepteerde meerdere statements. Zette je COMMIT; in de invoer, dan was de read-only transactie afgesloten en had de rest gewoon schrijfrechten.

Ik heb die truc nagespeeld tegen een PostgreSQL-gebruiker die alleen SELECT-rechten heeft:

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

-- ingelogd als agent_ro (uitvoer ingekort):
BEGIN TRANSACTION READ ONLY;
SELECT name FROM products LIMIT 1; COMMIT; DROP TABLE products;

COMMIT
ERROR:  must be owner of table products

De transactie gaat dicht, de tabel blijft staan. Een read-only-modus in de software rond de database is een belofte. Een databasegebruiker zonder rechten is een slot.

Leveranciers leren dat ook. Prisma vraagt sinds versie 6.15 (augustus 2025) eerst expliciete toestemming van de gebruiker als het herkent dat een agent zoals Claude Code of Cursor prisma migrate reset geeft. Microsofts SQL MCP Server (april 2026) laat het model bewust helemaal geen SQL schrijven: het krijgt alleen vooraf vrijgegeven tabellen en views te zien.

Dezelfde zoekvraag in vijf databases

Tabel products met een embedding van 1.536 dimensies, vijf dichtstbijzijnde producten op cosinus-afstand. De eerste drie heb ik gedraaid met 200 willekeurige vectoren van 1.536 dimensies. Oracle en SQL Server komen uit de officiële documentatie.

-- 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 (aparte virtuele tabel, koppelen 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 zoeken, gebruikt geen index)
SELECT TOP (5) id, name, VECTOR_DISTANCE('cosine', embedding, @q) AS distance
FROM products ORDER BY distance;

PostgreSQL en sqlite-vec gaven dezelfde vijf producten terug. De index van MariaDB miste het op één na beste product en zette een ander op plaats vijf. Dat is wat een benaderende index doet. Willekeurige vectoren zijn wel een lastig geval voor zo'n index; echte embeddings liggen meer in groepjes bij elkaar. Controleer het met je eigen data voordat je erop vertrouwt.

Vanuit PHP stuur je de zoekvector als tekst: json_encode($embedding) geeft het formaat [0.12,-0.03,…] dat PostgreSQL, MariaDB, SQLite en SQL Server accepteren. Bij Oracle kun je hem desnoods expliciet omzetten met TO_VECTOR(:q). Omdat de syntax per database verschilt, zou ik de vectorquery in één klasse of repository stoppen. Dan is overstappen later één bestand.

Welke database kies je voor welke webapplicatie?

Dit is mijn advies, gebaseerd op het bovenstaande. Kies de database eerst op de gewone eisen, zoals hosting, kennis in het team en bestaande data. Kies daarna de vectorroute die bij die database hoort. Een aparte vectordatabase is voor de meeste webapplicaties een extra systeem om te beheren, zonder dat je er iets voor terugkrijgt.

Ik werk zelf met Oracle, MySQL en SQLite; deze site draait op SQLite. Volgens dit lijstje hoort die site in de eerste rij, en de meting geeft daar ook alle reden toe.

Opvallend aan het geheel: juist de twee databases die het vaakst op goedkope hosting draaien, MySQL Community en kale SQLite, hebben de zwakste ingebouwde vectorondersteuning. De gratis uitweg ligt bij MariaDB en PostgreSQL. Van MySQL naar MariaDB is voor de meeste PHP-ontwikkelaars een kleine stap; naar PostgreSQL is het een echte migratie.

Laat je een AI-agent met je database werken, begin dan niet bij het model maar bij de inloggegevens. Maak een aparte databasegebruiker met alleen SELECT op de tabellen die de agent nodig heeft. Zet geen productiewachtwoorden of API-tokens in de map waarin de agent werkt. Bewaar back-ups ergens waar dezelfde token niet bij kan. De twee gewiste databases en het lek in de MCP-server uit dit artikel waren met die maatregelen niet gebeurd, hoe slim het model ook was. Dat is mijn lezing van de gepubliceerde verslagen; alleen de MCP-truc heb ik zelf nagespeeld.

Bronnen

• Oracle, AI Vector Search User's Guide 26ai, Approximate search using HNSW en VECTOR_MEMORY_SIZE; Oracle AI Database 26ai (14 oktober 2025); oracle-base over de limieten van 23ai Free
• Microsoft, What's new in SQL Server 2025, CREATE VECTOR INDEX en 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 en CREATE TABLE with Vectors
• MongoDB, overname Voyage AI (24 februari 2025) en Search en Vector Search GA voor Community Edition
• Stack Overflow Developer Survey 2026 en 2025; DB-Engines Ranking (oktober 2026)
• pgvector, README en CHANGELOG; Laravel 13, Migrations en Queries
• SQLite, release history; Alex Garcia, sqlite-vec stable release en releases; PHP-handleiding, SQLite3::loadExtension en Pdo\Sqlite::loadExtension
• Turso, DiskANN in libSQL en Turso is joining Supabase; DuckDB, VSS-extensie
• Databricks, Databricks Agrees to Acquire Neon (14 mei 2025); TechCrunch over Snowflake en Crunchy Data (2 juni 2025); Supabase, Lovable Cloud en Supabase is acquiring Turso (2 oktober 2026)
• BIRD-benchmark (ranglijst bekeken 30 oktober 2026); Lei e.a., Spider 2.0 (ICLR 2025)
• The Register, Replit over de gewiste database (22 juli 2025) en PocketOS (27 april 2026); Datadog Security Labs, SQL injection in the PostgreSQL MCP server (21 augustus 2025); Prisma, ORM 6.15.0