DanLevy.net

L'ondata di innovazione dei database del 2025

Potete ringraziare l'IA.

Non un altro articolo sui Vector DB

Ecco la regola decisionale che vorrei aver usato prima:

Se i tuoi dati possono essere ricostruiti da file e gli utenti li leggono principalmente, prova prima un database basato su object storage. Se gli utenti ci scrivono tutto il giorno, inizia con un vero database e smetti di cercare di far fare a S3 il cosplay di un database.

Questa è la linea utile. Non “il serverless è il futuro”. Non “i database vettoriali hanno cambiato tutto”. Queste frasi sono già state stampate su abbastanza laccetti da conferenza.

L’IA ha cambiato davvero la forma di molti problemi di ricerca. All’improvviso piccoli team volevano ricerca semantica, ranking ibrido, chat sui documenti, lookup multimodale e analisi su file seduti nell’object storage. La vecchia risposta era “esegui Postgres con pgvector” o “gestisci OpenSearch/Elasticsearch” o “acquista un servizio di ricerca gestito”. Quelle sono ancora buone risposte quando il carico di lavoro le merita.

Ma molti carichi di lavoro non le meritano. Sono carichi di lettura predominante, ricostruibili e tolleranti a un breve ritardo tra il cambiamento del contenuto e l’aggiornamento della ricerca. Documentazione. Snapshot di cataloghi. Esportazioni statiche. Basi di conoscenza interne. Analisi locali. Sistemi RAG prototipali. Per questi, una nuova classe di strumenti ha reso insolitamente potente l’architettura noiosa: costruisci un indice, memorizzalo come file, servilo via HTTP.

Nota istantanea: l’ecosistema si muove rapidamente. I conteggi delle stelle, le etichette delle funzionalità e i numeri delle prestazioni qui sotto sono un’istantanea di settembre 2025, non un tabellone senza tempo. Trattali come orientamento, poi controlla la documentazione corrente prima di scommettere una migrazione in produzione su una singola cella.

Un database con un altro nome

Questi datastore serverless e compatibili con CDN sono utili per casi di scala media, circa da 1.000 a 1.000.000 di record o qualche GB, dove l’infrastruttura tradizionale dei database può essere più cerimonia che valore:

La mossa comune è semplice: mantieni i dati durevoli in file o object storage, poi interrogali da un browser, funzione edge, worker o servizio leggero. Questo non elimina la complessità. Sposta la complessità nelle pipeline di build, nell’aggiornamento degli indici, nell’invalidazione della cache e nelle capacità del client. Che è un compromesso perfettamente valido quando le letture dominano.

Battaglia delle checkbox

FeaturePagefindOramaChromaLanceDBDuckDB-WASM
Ricerca Full-Text✅ Stemming avanzato✅ BM25, 30 lingue✅ SQLite FTS✅ Tantivy✅ SQL completo
Ricerca Vettoriale✅ Similarità coseno✅ HNSW✅ IVF_PQ, HNSW, GPU⚠️ Estensioni
Integrazioni IA/RAGNessuna✅ Pipeline integrata✅ LangChain, LlamaIndex✅ Reranking avanzato⚠️ Setup manuale
StorageJSON/WASM staticoPlugin memory + S3Basato su server*Lance compatibile S3WASM + S3/HTTP
Supporto scritturaSolo build-timeFull CRUDFull CRUDFull CRUDFull SQL CRUD
PrestazioniSub-100ms0,0001ms - 100msSub-100ms3-5ms vettoriale, 50ms FTS10ms-1s (SQL complesso)

*Istantanea settembre 2025: Chroma richiede un runtime server e non supporta l’object storage S3 diretto nel modo in cui lo fanno gli strumenti object-file (issue #1736).

Esempi di implementazione

Le differenze di sintassi rivelano la vera divisione: ricerca build-time, ricerca in-memory, storage vettoriale nativo, tabelle multimodali e SQL nel browser non sono la stessa categoria di prodotto solo perché appaiono tutti nelle demo di IA.

Ricerca per siti statici con Pagefind

<link href="/pagefind/pagefind-ui.css" rel="stylesheet">
<script src="/pagefind/pagefind-ui.js"></script>
<div id="search"></div>
<script>new PagefindUI({ element: "#search" });</script>

Multimodale enterprise-grade con LanceDB

Codice per creare una tabella LanceDB con embedding OpenAI automatici:

import * as lancedb from "@lancedb/lancedb";
import "@lancedb/lancedb/embedding/openai";
import { LanceSchema, getRegistry } from "@lancedb/lancedb/embedding";
import { Utf8 } from "apache-arrow";
const db = await lancedb.connect("data/multimodal-db");
const func = getRegistry()
.get("openai")
?.create({ model: "text-embedding-ada-002" });
// Schema con generazione automatica degli embedding
const documentsSchema = LanceSchema({
text: func.sourceField(new Utf8()),
vector: func.vectorField(),
category: new Utf8()
});
const table = await db.createEmptyTable("documents", documentsSchema);
await table.add([
{ text: "machine learning concepts", category: "research" },
{ text: "deep learning fundamentals", category: "research" }
]);

Esempio di interrogazione di una tabella LanceDB:

import * as lancedb from "@lancedb/lancedb";
import "@lancedb/lancedb/embedding/openai";
// "Connect" to a URL path
const db = await lancedb.connect("data/multimodal-db");
const table = db.getTable("documents");
// SQL + vector search combination
const results = await table.search("machine learning concepts")
.where("category = 'research'")
.limit(10)
.toArray();
console.log(results);

Ricerca universale con Orama

import { create, insert, search } from '@orama/orama'
const db = create({
schema: {
title: 'string',
content: 'string',
embedding: 'vector[1536]'
}
})
await insert(db, {
title: 'Getting Started',
content: 'Learn the basics',
embedding: await generateEmbedding('Learn the basics')
})
const results = await search(db, {
term: 'basics',
mode: 'hybrid' // Combines text + vector search
})

DuckDB-WASM:

import * as duckdb from "https://cdn.jsdelivr.net/npm/@duckdb/duckdb-wasm@latest/dist/duckdb-browser.mjs";
const bundle = await duckdb.selectBundle(duckdb.getJsDelivrBundles());
const worker = new Worker(bundle.mainWorker);
const db = new duckdb.AsyncDuckDB(new duckdb.ConsoleLogger(), worker);
await db.instantiate(bundle.mainModule, bundle.pthreadWorker);
const conn = await db.connect();
await conn.query(`create table t as select * from (values (1,'hybrid search'),(2,'edge sql')) as v(id,txt);`);
// Optional full-text:
await conn.query(`install fts; load fts; select * from t where match_bm25(txt, 'hybrid');`);

Ricerca nativa IA con Chroma

import { ChromaClient } from "chromadb";
const client = new ChromaClient();
const collection = await client.createCollection({ name: "knowledge-base" });
await collection.add({
documents: ["AI will transform software development"],
metadatas: [{ source: "tech-blog", category: "AI" }],
ids: ["doc1"]
});
const results = await collection.query({
queryTexts: ["future of programming"],
where: { category: "AI" },
nResults: 5
});

Guida ai casi d’uso

Scegli Pagefind quando:

Scegli Orama quando:

Scegli Chroma quando:

Scegli LanceDB quando:

Scegli DuckDB-WASM quando:

La regola decisionale

La domanda pratica non è “quale database è il migliore?”

La domanda pratica è: che tipo di cambiamento deve assorbire il sistema?

Il percorso felice è economico. Sono i casi limite a decidere l’architettura.

Il quadro più ampio

Questi strumenti riducono l’infrastruttura minima vitale per una ricerca utile. Questo conta. Nel 2020, “ricerca semantica” implicava spesso una pila di servizi, un sacco di codice colla e qualcuno che spiegava gli indici vettoriali in una riunione dove metà della stanza voleva il pranzo. Nel 2025, un piccolo team può prototipare la stessa idea di prodotto con file, embedding e un weekend.

Questo non significa che ogni casella di ricerca debba diventare un sistema RAG. Significa che la prima versione non deve più ereditare un’infrastruttura di produzione prima di avere prove di produzione.

Anche AWS si sta muovendo in questa direzione con il lavoro di ricerca vettoriale adiacente a S3, che è un segnale utile: l’object storage non è più solo la soffitta dove finiscono i vecchi file. Sta diventando una superficie di interrogazione.

Inizia a sperimentare

  1. Scegli prima il pattern di aggiornamento: build-time, batch orario, scritture live o risultati per utente.
  2. Prototipa con lo strumento più piccolo onesto: Pagefind per HTML statico, DuckDB per file analitici, Orama per ricerca leggera nelle app, LanceDB o Chroma per lavoro vettoriale pesante.
  3. Misura la parte brutta: tempo di indicizzazione, freschezza, dimensione del bundle, permessi e la prima query dopo un avvio a freddo.
  4. Promuovi solo quando il dolore è reale: un database gestito è più facile da giustificare dopo che la versione basata su file mostra esattamente dove si piega.

Scopri la mia guida pratica a Pagefind per un’implementazione pratica, o esplora il crescente ecosistema di database edge-native che stanno rimodellando i dati su larga scala.

Disclaimer: Ho usato Pagefind per anni e sono diventato un contributore nel 2025. Ho sperimentato con Orama e Chroma per progetti più piccoli e sto esplorando LanceDB per applicazioni IA più grandi. Nessun legame finanziario con questi progetti—solo un vivo interesse nel panorama dei database in evoluzione.