Ein Schema.
Jedes SQL-Backend.
Dein Schema, deine Queries, Migrationen und die reaktive Engine werden einmal geschrieben und zur Laufzeit in das dialekt-native Idiom kompiliert. Postgres ist die Referenz; MySQL, MariaDB, MSSQL und SQLite laufen denselben Code. Die Auswahl ist eine einzige Env-Variable — DB_DIALECT.
// database/posts.entity.ts — one schema, any dialect
import { id, table, text, timestamp } from '@voltro/database'
export const posts = table('posts', {
id: id(), // branded TypeID
body: text(), // NOT NULL by default
createdAt: timestamp(), // timestamptz, UTC
}).reactive()
// Switch backend with one env var — the DDL, query
// builder and CDC reader all adapt:
// DB_DIALECT=postgres # LISTEN/NOTIFY
// DB_DIALECT=mysql # binlog CDC
// DB_DIALECT=sqlite # in-process busWas mit @voltro/database mitkommt.
Eine DSL, ein Query-Builder
table() + Spalten + Mixins deklarieren das Schema; ein einziger cross-dialekt Query-Builder emittiert dialektspezifisches SQL. Spalten sind standardmäßig NOT NULL; ids sind standardmäßig branded TypeIDs. Du schreibst Voltro, nicht Postgres-spezifisches Voltro.
Natives Change-Data-Capture
Reaktivität kommt aus echtem CDC: Postgres LISTEN/NOTIFY, MySQL/MariaDB Binlog (ROW-Format), MSSQL Change Tracking und ein In-Process-Bus für SQLite. Resume-Offsets werden persistiert, damit ein Neustart keine Änderung verpasst.
Migrationen, geplant & online
voltro db plan / apply mit Drift-Erkennung, Squashing, Rollback + Snapshots, Cross-Env-Sync und Zero-Downtime-Online-Änderungen — das richtige DDL für den gewählten Dialekt wird emittiert.
Reiche SQL-Oberfläche
Joins mit Eager Loading über dialekt-native JSON-Aggregation, Window-Funktionen, rekursive CTEs, DISTINCT ON, Set-Operationen, typisiertes JSON/JSONB, Arrays, Generated Columns, Volltextsuche und pgvector-Ähnlichkeit.
Read-Replicas + Read-your-Writes
Richte DB_REPLICA_URLS auf Replicas und Reads verteilen sich; pro-Subject-Read-your-Writes verfolgt LSN/GTID, sodass ein Nutzer nie älter liest als sein eigener letzter Write. (Postgres-RYW ist vollständig; MySQL/MariaDB-Wait-Mode routet heute auf Primary.)
Portabel, nicht kleinster gemeinsamer Nenner
Die DSL verbirgt die Abweichung jedes Dialekts — DDL-Emitter, JSON-agg-Compiler und FTS-Syntax wechseln mit DB_DIALECT — erreicht aber trotzdem dialekt-native Features. Turso ist ein Beta-Dialekt; Geld sind ganzzahlige Minor Units (noch kein DECIMAL-Typ).
Sechs Backends, ein mentales Modell.
Die dialektübergreifende Wette:
Postgres, MySQL, MariaDB, MSSQL und SQLite bekommen jeweils DB_DIALECT -getriebene Emission — Query-Builder, Migrations-Planer und CDC-Reader passen sich an. Postgres bleibt das empfohlene Ziel für native LISTEN/NOTIFY-Reaktivität; die anderen sind für Enterprise-Beschaffung und Embedded-Workloads da.
Für Dialekte ohne natives Cross-Instance-CDC (SQLite) oder hinter einem Load Balancer ergänze @voltro/plugin-broadcast , um Änderungen über Redis oder NATS über Replicas zu fächern.
Das Schema speist den Rest der Runtime.
Schema-DSL
Komponiere Tabellen mit Mixins — Audit, Tenant, Soft-Delete — eine Zeile pro Querschnittsbelang.
Reaktive Queries
.reactive() nimmt eine Tabelle in die Matcher-Engine auf, damit ihre Writes Subscriptions wecken.
Realtime & Fan-out
Natives CDC plus plugin-broadcast halten Reaktivität über eine Multi-Replica-Flotte am Laufen.
Öffne das Framework. Schau es dir selbst an.
Jede Primitive auf dieser Seite ist heute im Framework. Klone den Starter, lass `voltro dev` laufen, in zwei Minuten ist es auf dem Bildschirm.