Wat AWS aankondigde

Op 5 augustus 2026 kondigde AWS aan dat Amazon DynamoDB vectorzoeken nu native afhandelt, zonder dat daarvoor een aparte vectorindex hoeft te worden gebouwd of onderhouden. Het bedrijf noemt een latentie van enkele milliseconden bij een recall van meer dan 99 procent, schaalbaar tot biljoenen vectoren. SiliconANGLE en InfoWorld berichtten die dag onafhankelijk van elkaar over de aankondiging en omschreven het als een native mogelijkheid in plaats van een los aangekoppelde dienst.

Het mechanisme is eenvoudig: vectorzoeken draait nu op dezelfde tabel die al de primaire toepassingsgegevens bevat. Er is geen tweede database meer nodig, geen export-en-importstap, en geen pijplijn die een aparte vectorindex synchroon moet houden met wijzigingen in de brontabel.

Vooral dat laatste punt is de moeite waard. Het wegvallen van de synchronisatiepijplijn schrapt de vertraging tussen een update van een record en het verschijnen daarvan in de zoekresultaten, en het schrapt de hele categorie fouten die ontstaat wanneer twee dataopslagen uit elkaar gaan lopen.

De leverancierscategorie die dit bedreigt

De afgelopen twee a drie jaar betekende het toevoegen van semantisch zoeken of retrieval-augmented generation (RAG) aan een product bijna altijd het invoeren van een tweede, speciaal daarvoor gebouwde vectordatabase naast de database die de echte gegevens al bevatte. Pinecone, Weaviate en Milvus bouwden hun bedrijf precies op dat gat, en Postgres-extensies vulden dezelfde behoefte in voor teams die bij een enkele engine wilden blijven.

Dat patroon werd bijna een vaste post in AI-projectplannen: budget voor een vectordatabase-leverancier, budget aan engineering-tijd voor een synchronisatiepijplijn, en budget voor een tweede beveiligingsbeoordeling omdat gebruikersgegevens nu door een tweede verwerker stromen. Geen van die kosten was uitzonderlijk, maar ze werden allemaal als noodzakelijk beschouwd.

Wat AWS op 5 augustus uitbracht, schrapt die leverancierscategorie niet, maar het haalt in een groot, veelvoorkomend geval de automatische rechtvaardiging eronder vandaan: elk team wiens primaire toepassingsgegevens al in DynamoDB staan. Voor die groep moet het argument voor een aparte vectordatabase nu opnieuw worden bewezen in plaats van te worden aangenomen.

Wat te controleren voor de volgende go voor een AI-project

De praktische instructie is eenvoudig en direct. Voordat een contract met een vectordatabase-leverancier wordt getekend, en voordat een engineer wordt ingezet om een synchronisatiepijplijn van DynamoDB naar een vectordatabase te bouwen, zou iemand moeten nagaan of DynamoDB dit werk nu zelf al aankan.

Dit telt vooral voor plannen die al geschreven waren. Elk AI-projectplan van de afgelopen twee jaar met een regel voor 'aparte vectordatabase toevoegen' werd geschreven onder aannames die AWS nu net heeft veranderd voor DynamoDB-gebruikers. Dat plan heropenen kost een middag; het niet heropenen kost een leverancierscontract en een onderhoudspijplijn die misschien niet nodig was.

De controle zelf is beperkt: staan de primaire toepassingsgegevens al in DynamoDB, en vallen de vereiste schaal en latentie binnen wat AWS heeft gepubliceerd? Als beide antwoorden ja zijn, wordt de aparte vectordatabase optioneel in plaats van vanzelfsprekend.

Waar een aparte vectordatabase nog steeds zin heeft

Niets hiervan betekent dat elke eigen vectordatabase moet worden verwijderd. Teams die op extreme schaal werken, of over meerdere cloudleveranciers heen, kunnen nog steeds redenen hebben die niets met de nieuwe mogelijkheid van DynamoDB te maken hebben.

Architecturen die al stabiel zijn opgebouwd rond Pinecone, Weaviate of Milvus hoeven ook niet te veranderen op basis van een enkele aankondiging. Migreren heeft zijn eigen kosten, en een werkend systeem dat aan de eisen voldoet, verdient niet automatisch om te worden aangeraakt.

Het eerlijke standpunt is dat dit een hercontrole is, geen verplichting. Sommige teams zullen de controle uitvoeren en hun aparte vectordatabase behouden omdat ze daar een echte reden voor hebben. De fout is niet het controleren, maar juist helemaal niet controleren en uit gewoonte bij de oude aanname blijven.

Wat nu te volgen

Het meest directe gevolg voor privacyteams in de EU en het VK is een compliance-kwestie: elk team dat zijn vectorzoeken naar DynamoDB verplaatst, haalt een tweede verwerker en een tweede verwerkersovereenkomst uit zijn leveranciersbeoordeling, omdat gebruikersgegevens niet langer via een aparte vectordatabase-leverancier hoeven te lopen.

Het is de moeite waard om te zien hoe de gespecialiseerde vectordatabase-leveranciers reageren. Zo'n mogelijkheid, uitgebracht door de leverancier die al een groot deel van de onderliggende gegevens beheert, is het soort zet dat concurrenten vaak dwingt zich duidelijk te onderscheiden of harder op prijs te concurreren.

Het is ook de moeite waard om te zien of andere grote cloud-databaseleveranciers de komende maanden vergelijkbare vectormogelijkheden in hun eigen primaire databases inbouwen. Als de zet van AWS elders wordt nagevolgd, raakt de aanname dat AI-functies een aparte database nodig hebben, ver voorbij DynamoDB verouderd.

Lees hierna: De orderportefeuille was 1,5 miljard. De obligatie ook.  |  De schaarstewinst vertrok als aandeleninkoop