VoltroFramework

One schema.
Every SQL backend.

Your schema, queries, migrations and the reactive engine are written once and compile to the dialect-native idiom at runtime. Postgres is the reference; MySQL, MariaDB, MSSQL and SQLite run the same code. Selecting one is a single env var — DB_DIALECT.

Read the quickstart
posts.entity.ts
TypeScript
// 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 bus

What ships with @voltro/database.

One DSL, one query builder

table() + columns + mixins declare the schema; a single cross-dialect query builder emits per-dialect SQL. Columns are NOT NULL by default; ids default to branded TypeIDs. You write Voltro, not Postgres-specific Voltro.

Native change-data-capture

Reactivity is powered by real CDC: Postgres LISTEN/NOTIFY, MySQL/MariaDB binlog (ROW format), MSSQL Change Tracking, and an in-process bus for SQLite. Resume offsets are persisted so a restart doesn’t miss a change.

Migrations, planned & online

voltro db plan / apply with drift detection, squashing, rollback + snapshots, cross-env sync and zero-downtime online changes — emitting the right DDL for whichever dialect you target.

Rich SQL surface

Joins with eager loading via dialect-native JSON aggregation, window functions, recursive CTEs, DISTINCT ON, set operations, typed JSON/JSONB, arrays, generated columns, full-text search and pgvector similarity.

Read replicas + read-your-writes

Point DB_REPLICA_URLS at replicas and reads spread across them; per-subject read-your-writes tracks LSN/GTID so a user never reads staler than their own last write. (Postgres RYW is complete; MySQL/MariaDB wait-mode routes to primary today.)

Portable, not lowest-common-denominator

The DSL hides each dialect’s divergence — the DDL emitter, JSON-agg compiler and FTS syntax all switch with DB_DIALECT — while still reaching dialect-native features. Turso ships as a beta dialect; money is integer minor units (no DECIMAL type yet).

Six backends, one mental model.

The cross-dialect bet:

Postgres, MySQL, MariaDB, MSSQL and SQLite each get DB_DIALECT -driven emission — the query builder, migration planner and CDC reader all adapt. Postgres remains the recommended target for native LISTEN/NOTIFY reactivity; the others exist for enterprise procurement and embedded workloads.

For dialects without native cross-instance CDC (SQLite) or behind a load balancer, add @voltro/plugin-broadcast to fan changes across replicas over Redis or NATS.

The schema feeds the rest of the runtime.

Schema DSL

Compose tables with mixins — audit, tenant, soft-delete — one line per cross-cutting concern.

Reactive queries

.reactive() opts a table into the matcher engine so its writes wake subscriptions.

Real-time & fan-out

Native CDC plus plugin-broadcast keep reactivity working across a multi-replica fleet.

Open the framework. See it for yourself.

Every primitive on this page is in the framework today. Clone the starter, run `voltro dev`, and have it on screen in two minutes.

Read the quickstart