Aurabase vs Convex: SQL nativo o backend reattivo?

Aurabase si basa sullo standard PostgreSQL 16: SQL, migrazioni classiche, policy RLS. Convesso prende il percorso opposto. La sua documentazione ufficiale è esplicita su questa scelta: "Non c'è nulla da impostare e non è necessario scrivere alcun SQL. Usa semplicemente JavaScript per esprimere le esigenze della tua app" (docs.convex.dev/database, accesso il 24 agosto 2026). Le tabelle convesse memorizzano i documenti digitati da uno schema TypeScript opzionale, creato inizialmente insert, senza DDL da scrivere.

Ecco come appare una tipica query Convex, con un indice dichiarato nello schema:

// Query convessa: TypeScript, non SQL
import { query } from './_generated/server'
import { v } from 'convex/values'

export const getOpenTasks = query({
  args: {},
  handler: async (ctx) => {
    return await ctx.db
      .query('tasks')
      .withIndex('by_completed', q => q.eq('completed', false))
      .collect()
  },
})

Nessuno dei due modelli è strettamente superiore. Il generatore di query di Convex elimina un'intera classe di bug di SQL injection per costruzione. Ti blocca anche nel suo linguaggio di query. Nessuno strumento di BI standard, nessun ORM Postgres esistente, nessuna estensione SQL come pgvector o pg_graphql senza una riscrittura completa del livello dati.

In Convex, qualsiasi query risponde per impostazione predefinita. Il client apre una connessione WebSocket alla distribuzione e il motore conserva tutte le righe lette da ciascuna richiesta (il suo "set di letture"). Non appena una mutazione influisce su questo set di lettura, la funzione viene riprodotta sul lato server. Il risultato aggiornato viene inviato al client, senza codice di abbonamento da scrivere (stack.convex.dev/how-convex-works, accesso il 24 agosto 2026).

Aurabase realtime funziona in modo opposto, in modalità opt-in. NATS JetStream trasmette il flusso di modifiche PostgreSQL (CDC); ti iscrivi esplicitamente a un canale tramite channel().on('postgres_changes', …), con possibile filtraggio per colonna. Si tratta di più codice da scrivere per una visualizzazione live, ma di un protocollo standard supportato dalla replica logica Postgres, non di un meccanismo proprietario abbinato a uno specifico generatore di query.

Un punto in comune che non ci aspettiamo di trovare qui: entrambi i motori sono scritti in Rust. Il repository open source Convex (get-convex/convex-backend) è composto principalmente da crate Rust. TypeScript viene utilizzato solo per l'ambiente di esecuzione delle funzioni di sviluppo, tramite il motore V8 (stack.convex.dev/how-convex-works, accesso il 24 agosto 2026). Contro Supabase — Elixir/Go/TypeScript/Node stack — il core Rust rimane un vero elemento di differenziazione di Aurabase. Contro Convex no: entrambi hanno fatto questa scommessa, ciascuno per costruire un motore transazionale affidabile senza pause imprevedibili nella raccolta dei rifiuti.

La differenza sta nella licenza. Il codice del motore Convex (get-convex/convex-backend) è rilasciato sotto FSL-1.1-Apache-2.0, una licenza sorgente equa. Si autorizza qualsiasi utilizzo salvo la creazione di un prodotto concorrente con Convex Cloud. Ogni versione passa ad Apache 2.0 puro due anni dopo essere stata resa disponibile: clausola verificata direttamente nel file LICENSE.md nel repository (github.com/get-convex/convex-backend, accesso il 24 agosto 2026). L'area di lavoro Rust e l'SDK JavaScript di Aurabase sono pubblicati sotto la licenza MIT, open source senza ritardi o restrizioni di utilizzo.

Convesso non è escluso dall'intelligenza artificiale. La sua ricerca vettoriale nativa è accessibile da actions, con un indice vettoriale dichiarato nello schema. Con il suo framework @convex-dev/agent e rag.search(), forma una funzionalità RAG paragonabile, sulla carta, al RAG nativo di Aurabase (docs.convex.dev/search/vettoriale-search, accesso il 24 agosto 2026).

La vera differenza quindi non è “RAG contro nessun RAG”. Aurabase integra anche un motore NL2SQL: traduzione di una domanda in linguaggio naturale in una query SQL, convalidata e poi limitata prima dell'esecuzione. Convex non può strutturalmente offrire un equivalente: senza SQL da tradurre, non c'è nulla da generare. Questa è una conseguenza diretta della scelta dell'architettura sopra documentata, non un ritardo del prodotto.

Convex offre una regione EU West (Ireland), distribuita dal 6 febbraio 2026, oltre alla regione predefinita degli Stati Uniti orientali (docs.convex.dev/production/regions e news.convex.dev, accesso il 24 agosto 2026). Una vera opzione che merita di essere riconosciuta. Ma Convex Inc. rimane una società di diritto americano. Il suo fondatore e CEO, Jamie Turner, afferma di avere sede a San Francisco (news.convex.dev, raccolta di 57 milioni di dollari nella serie B guidata da Insight Partners, 4 agosto 2026). La scelta della regione Irlanda non modifica la giurisdizione della società che ospita i tuoi dati.

Questo è esattamente lo stesso meccanismo documentato con Supabase. Una regione europea controllata in un pannello amministrativo non è sufficiente per uscire dal regime giuridico del CLOUD Act finché la società madre resta americana. Aurabase SAS, società di diritto francese, gestisce un'infrastruttura produttiva verificata in Germania (Norimberga, Falkenstein) e Finlandia (Helsinki).

Approfondisci: perché il CLOUD Act cambia la tua scelta di BaaS

Convex ha preso una posizione pubblica contro la corsa ai benchmark di marketing. Il titolo del suo post non ha sfumature: "Non mi interessano i benchmark del tuo database (e nemmeno tu dovresti)" (stack.convex.dev/on-competitive-benchmarks, accesso il 24 agosto 2026). Una scelta di postura scontata, non un attacco mirato: il post non nomina nessun concorrente in particolare.

La posizione di Aurabase si basa sulla stessa osservazione ma va nella direzione opposta: pubblicare una metodologia di benchmark riproducibile e datata piuttosto che rinunciare a pubblicare dati. Questo è ancora un lavoro in corso: in questo articolo non vengono evidenziati dati sulle prestazioni finché non saranno accompagnati dalla sua metodologia completa.

Convex fa una scelta radicale: un unico linguaggio, dallo schema alla funzione server fino al client React, con digitazione end-to-end senza generazione manuale. Si tratta di un vero e proprio incremento di produttività per un team che è già TypeScript al 100%.

Aurabase JavaScript SDK è distribuito in pacchetti da 10 npm etichettati @aurabase/*, tutti pubblicati e installabili. Nel repository sono presenti anche gli SDK Python, Dart e Rust. Nessuno dei tre è ancora pubblicato sui rispettivi registri (PyPI, pub.dev, crates.io): per il momento sono installabili solo in dipendenza da un repository Git. Copertura multilingue più ampia sulla carta, con un reale divario esecutivo da colmare prima di rivendicarla completamente.

Aurabase si basa sullo standard PostgreSQL 16 e su un'API compatibile con PostgREST. L'esportazione di schemi e dati viene eseguita con il classico pg_dump/pg_restore — su Aurabase o su qualsiasi altro Postgres.

Convex non si basa su SQL: non esiste un equivalente diretto all'esportazione in un formato relazionale standard. La migrazione di un'applicazione Convex a un backend SQL implica il rimodellamento dello schema in tabelle relazionali e la riscrittura del livello di accesso ai dati, non solo la conversione di un file di esportazione.

Se il tuo team è già TypeScript al 100%, sta costruendo un'app React reattiva e non fa molto affidamento sulle estensioni SQL o Postgres, Convex ha un vero vantaggio di prodotto. Due vantaggi concreti: reattività automatica senza configurazione e digitazione end-to-end che riduce un'intera classe di bug di integrazione frontend/backend.

Il compromesso si verifica quando SQL, RLS Postgres, la portabilità dei dati o una regione di hosting in Germania/Finlandia con una società madre francese diventano criteri decisionali. È qui che Aurabase costruisce il suo elemento di differenziazione.

Vuoi un confronto focalizzato su open source e self-hosting? Vedi Aurabase vs Appwrite. Per il confronto dei benchmark e dell'architettura di Postgres, vedere Aurabase vs Supabase.