Seven storage models. One product definition.
An entity in Vadyl declares what it means in your product — fields, relations, access, invariants. The platform picks the storage model that fits: relational for normalized rows, document for nested aggregates, KV for hot lookups, graph for traversal, wide-column for scale, time-series for points, vector for similarity. Same product model. Same SDK. Different physics under the hood.
Each one a peer. No second-class persistence.
StorageModelKind drives routing through ReadCoordinator and WriteCoordinator. The same access policy, the same field security, the same audit trail apply across every model.
Relational
PostgreSQL, SQL Server, MySQL. Native joins, transactional DDL, sequences, identity columns, RLS, CHECK constraints, generated columns. Capability-aware DDL planning per provider.
Document
MongoDB native, plus SQL-document mode (JSONB on relational backends). Nested aggregates, arrays, schema validation. Document AST compiles to aggregation pipelines or BSON.
Key-value
Redis. KvGet / KvPut / KvDelete / KvScan / KvBatchGet / KvBatchPut / KvExpire / KvTtl. TTL-aware, atomic, capability-flag-gated for cluster mode.
Graph
Neo4j. VertexScan, EdgeScan, Traverse, GraphMatch, ShortestPath, Neighbors. Mutations: UpsertVertex / UpsertEdge / DeleteVertex / DeleteEdge — all compiled to parameterized Cypher.
Wide-column
Cassandra. CQL with LWT (IF NOT EXISTS / IF col = value). Compensation-only transactions — distributed atomicity via Vadyl's saga, not 2PC.
Time-series
MongoDB native time-series collections (≥6.0). Bucket policy, downsample rollups, retention windows. Capability-gated — providers below the floor degrade to companion adapters honestly.
Vector (similarity)
PostgreSQL pgvector ≥0.7. Native HNSW / IVFFlat. Cosine, L2, inner product. Hybrid search. Below the floor: companion vector index. Capability-aware fallback, never silent.
Cross-model entities
An entity can be relational on Postgres in one project and document on Mongo in another. Vadyl picks the strategy from declared StorageModel + provider capabilities.
Same product model. Different execution per provider.
The canonical model is intentionally richer than any single provider. Vadyl branches on structured capability categories per-feature, per-provider — delegate natively, supplement at runtime, orchestrate across providers, compensate where distributed behavior demands it.
DML, query, join, pagination, types
27 categories
Text, identity, indexing, constraints, DDL
160 flags
Schema objects, transactions, aggregation
0 unconsumed
Functions, predicates, auto-generation
Capability-gated
Namespace, security, cryptography
Native + runtime hybrid
Change tracking, storage model, document, KV, graph
Per-storage
Consistency, transition, database sources
Provider-driven
Time-series, vector augmentation
Capability-aware fallback
Compensation, isolation, savepoints
Drives commit strategy
All canonical, all peer
160 flags, every flag consumed
Vadyl never degrades silently
The same one across every storage shape
Pick the model that fits. Or let Vadyl pick.
Define an entity. Declare its storage model — or let the platform decide based on usage shape. Either way, your code reads the same.