[{"data":1,"prerenderedAt":228},["ShallowReactive",2],{"tag-database":3},[4],{"id":5,"title":6,"body":7,"categories":209,"coverImage":211,"date":212,"description":213,"extension":214,"meta":215,"navigation":216,"path":217,"seo":218,"stem":219,"sticky":220,"tags":221,"__hash__":227},"articles/la-storia-si-ripete.md","La storia si ripete",{"type":8,"value":9,"toc":199},"minimark",[10,17,26,31,34,37,51,58,61,64,68,74,77,83,87,90,96,99,103,125,132,135,142,152,156,159,165,168,171,176,180,186,196],[11,12,13],"p",{},[14,15,16],"em",{},"Graph database, MongoDB, vector database dedicati. Il pattern è sempre lo stesso. Solo i nomi cambiano.",[11,18,19,20,25],{},"Nel ",[21,22,24],"a",{"href":23},"/il-cms-in-c-che-non-ho-mai-scritto","post precedente"," ho raccontato di come nel 2015 ho scelto \"il solito\" WordPress per creare una piattaforma usata da decine di migliaia di persone. Ma c'è un'altra storia di quegli anni che vale la pena raccontare.",[27,28,30],"h2",{"id":29},"_2015-i-graph-database-erano-il-futuro-nosql-il-presente","2015: i graph database erano il futuro, noSQL il presente",[11,32,33],{},"Ogni conferenza, ogni blog post, ogni dev entusiasta. \"Le foreign key non scalano. I join sono roba vecchia. Il mondo è fatto di connessioni.\" Neo4j, Cypher, slide piene di nodi colorati e frecce.",[11,35,36],{},"Sullo stesso tono di guerra ai classici relazionali, le milioni di persone che si sono riversata su una unica combo, che quasi faceva da sinonimo a startup: nodejs + mongodb.",[11,38,39,40,43,44,43,47,50],{},"Partecipavo spesso a demo day tecnici dove CTO di altre startup raccontavano come stavano impostando la loro tecnologia.\nRicordo ancora uno ha esordire, appunto, con il classico dell'epoca: \"useremo node in accoppiata con mongo!\".\nPoi ha iniziato a descrivere il dominio: ",[14,41,42],{},"\"la relazione con\"",", ",[14,45,46],{},"\"la relazione di\"",[14,48,49],{},"\"questo è collegato a quello tramite quell'altro\"",".",[11,52,53,54],{},"Ho detto: ",[55,56,57],"strong",{},"\"Che follia sarebbe stata salvare le relazioni in un db... relazionale, vero?\"",[11,59,60],{},"Oggi uso Postgres per quasi tutto. Quando mi serve qualcosa in più pesco a piene mani da estensioni per lo stesso : pgvector per i vettori, timescale per time series, pg_textsearch per full text con ranking.",[11,62,63],{},"Graph database: zero.",[27,65,67],{"id":66},"cosa-è-successo","Cosa è successo",[11,69,70,71],{},"Niente di drammatico. ",[55,72,73],{},"Postgres è andato avanti.",[11,75,76],{},"Recursive CTE, jsonb, estensioni per tutto. Ha cannibalizzato il 90% dei casi d'uso senza aggiungere un componente infrastrutturale in più da mantenere, sincronizzare, monitorare e pagare.\nIl costo operativo di un grafo dedicato non è banale: lo sharding è complicato, e il modello mentale è diverso da quello relazionale che la maggior parte degli sviluppatori ha già interiorizzato.",[11,78,79,80,50],{},"Risultato: ottimo strumento per nicchie specifiche — fraud detection su scala enterprise, knowledge graph in grandi organizzazioni. Per il 95% dei progetti: ",[55,81,82],{},"overkill",[27,84,86],{"id":85},"la-stessa-storia-prima","La stessa storia, prima",[11,88,89],{},"Prima dei graph database c'era stato MongoDB.",[11,91,92,95],{},[14,93,94],{},"\"I join non scalano\""," — ripetuto come un mantra da chi non aveva mai avuto problemi di scala.\nDue anni dopo: array di userId dentro il documento ordine, ma alcuni stringhe, alcuni numeri altri ObjectId e manca il 3% dei riferimenti, e nessuno sa perché.",[11,97,98],{},"MongoDB era genuinamente utile per alcuni casi d'uso e anch'io l'ho usato tantissimo (più frequentemento a fianco anziché in sostituzione).\nIl problema era che veniva usato per tutto, perché era nuovo, perché era cool, perché usarlo sembrava una scelta moderna.",[27,100,102],{"id":101},"il-pattern-è-sempre-lo-stesso","Il pattern è sempre lo stesso",[104,105,106,110,113,116,119,122],"ol",{},[107,108,109],"li",{},"Tecnologia nuova risolve problemi reali in casi specifici",[107,111,112],{},"Viene presentata con casi d'uso di aziende con scala che il 99% dei team non avrà mai",[107,114,115],{},"Viene adottata come soluzione generale",[107,117,118],{},"Chi usa la tecnologia \"noiosa\" sembra un fossile",[107,120,121],{},"Arriva il momento dei conti",[107,123,124],{},"La tecnologia noiosa è ancora lì, qualcuno propone un refactor \"per irrobustire\" (leggasi tornare a schemi e contratti solidi), che durerà un anno.",[11,126,127,128,131],{},"C'è un concetto che si chiama ",[55,129,130],{},"Lindy Effect",": una tecnologia che esiste da vent'anni probabilmente esisterà altri vent'anni.",[11,133,134],{},"Ve lo dice uno che è smanettone e enthusiast dalla nascita: conoscere tutto, sperimentare tutto, ma in produzione... Dipende.",[11,136,137,138,141],{},"Il nostro mestiere è ",[55,139,140],{},"identificare contesti in cui è necessario operare scelte \"a mestiere\""," anche considerando aree di rischio come il supporto sul lungo periodo,\nla reperibilità (e dunque i costi) di risorse schillate in quella tecnologia col crescere del team, trasferimento di competenze, disponibilità di estensioni/librerie già pronte e battle-tested.",[11,143,144,147,148,151],{},[55,145,146],{},"E lo so che riusare qualcosa che usi da 20 anni è noioso",", ma a volte è anche il servizio più professionale che possiamo rendere. Per il brivido della novità basta un po' di pazienza e\ncertamente l'universo ci manderà il progetto in cui avrà veramente senso utilizzare la novità. Nel frattempo ci sono i vari progetti personali ",[14,149,150],{},"for fun"," come sfogo.",[27,153,155],{"id":154},"sta-succedendo-adesso","Sta succedendo adesso",[11,157,158],{},"Pinecone, Weaviate, Chroma. Vector database dedicati, presentati come componente necessario di qualsiasi architettura AI.",[11,160,161,162,50],{},"Anche qui: non è che siano inutili. È che nella stragrande maggioranza dei casi ",[55,163,164],{},"non ne hai bisogno",[11,166,167],{},"Una ricerca ibrida full-text con BM25 + pgvector risolve il grosso — con il vantaggio di avere tutto nello stesso database, relazioni intatte, zero sincronizzazioni, zero componenti aggiuntivi da mantenere. Fino a circa mezzo milione di record la differenza di performance rispetto a un vector database dedicato è risibile. E la maggior parte dei progetti non arriverà mai a mezzo milione di record.",[11,169,170],{},"Il costo dell'infrastruttura esotica lo paghi sempre dopo, mai subito. E \"dopo\" coincide quasi sempre con il momento peggiore: trazione reale, investitori che guardano, utenti che si lamentano.",[11,172,173],{},[55,174,175],{},"La storia è ciclica. Solo i nomi cambiano.",[27,177,179],{"id":178},"il-mio-mantra","Il mio mantra",[181,182,183],"blockquote",{},[11,184,185],{},"Minimum diff, less moving parts.",[11,187,188,189,192,193],{},"Nei progetti ho una regola che mi porto dietro da anni: ",[55,190,191],{},"minimum diff, less moving parts",". Ogni componente aggiuntivo è una dipendenza, una cosa che può rompersi e che ha side effects a volte impliciti. Una cosa che qualcuno\ndeve capire, mantenere, aggiornare. ",[55,194,195],{},"Il costo non è mai solo tecnico — è cognitivo, operativo, economico.",[11,197,198],{},"Scegliere la tecnologia più \"dritta\" che risolve il problema non è una scorciatoia. È il mestiere.",{"title":200,"searchDepth":201,"depth":201,"links":202},"",2,[203,204,205,206,207,208],{"id":29,"depth":201,"text":30},{"id":66,"depth":201,"text":67},{"id":85,"depth":201,"text":86},{"id":101,"depth":201,"text":102},{"id":154,"depth":201,"text":155},{"id":178,"depth":201,"text":179},[210],"Dev","https://i2.wp.com/enricodeleo.s3.eu-south-1.amazonaws.com/images/la-storia-si-ripete.png","2026-03-30T10:00:00.000Z","Nel 2015 i graph database erano il futuro. Oggi uso Postgres per quasi tutto. Nel mezzo: MongoDB, ObjectId misti, e il solito conto arrivato dopo. Sta succedendo di nuovo con i vector database.","md",{},true,"/la-storia-si-ripete",{"title":6,"description":213},"la-storia-si-ripete",false,[222,223,224,225,226],"postgres","database","engineering","tech-debt","build-in-public","VEFCqWkv1Yjj6bCK7VDZSq71yRGNeyfN3gYqOWZux44",1775418697407]