vcl-vs-sql.adoc

VCL vs SQL: A Comparative Guide

Table of Contents

• 1. Introduction
• 2. Concept Comparison
• 3. SQL Features: What VCL Has and Lacks
• 4. What VCL Has That SQL Lacks
• 5. Example Comparisons
  • 5.1. Retrieving an Entity
  • 5.2. Finding Related Entities
  • 5.3. Full-Text Search
  • 5.4. Similarity Search
  • 5.5. Verified Query (No SQL Equivalent)
• 6. Summary

1. Introduction

VCL (VeriSim Consonance Language) is the query language for VeriSimDB, an eight-modality database. While VCL borrows familiar keywords from SQL (SELECT, FROM, WHERE, LIMIT, OFFSET), it serves a fundamentally different purpose.

VCL’s preferred write path is the Octad API (Rust core or Elixir orchestration layer), not the language. VeriSimDB treats writes as coordinated multi-modal operations that must maintain consistency across all eight modality stores (Graph, Vector, Tensor, Semantic, Document, Temporal, Provenance, Spatial), and a bare INSERT cannot by itself express the cross-modal invariants an octad write requires.

That said, VCL is not read-only. An earlier revision of this page said it was; the normative grammar and the implemented parser disagree, and VCL-SPEC.adoc lists the "read-only" description as a known inconsistency resolved in favour of the implementation. spec/grammar.ebnf v3.0 defines statement = query | mutation ; with INSERT HEXAD, UPDATE HEXAD … SET … and DELETE HEXAD …, each accepting an optional PROOF clause; src/vcl/VCLParser.affine implements all three and src/vcl/VCLBidir.affine type-checks them. These SQL-shaped mutation forms are retained for backward compatibility. For verified cross-modal writes, use the Octad API or attach a PROOF clause.

VCL is multimodal. Where SQL selects columns from relational tables, VCL selects modalities from octad stores or federations. A single VCL query can retrieve graph edges, vector embeddings, tensor slices, semantic annotations, document text, and temporal versions in one pass.

VCL is federation-aware. Queries can target a local STORE, a specific HEXAD entity, or a FEDERATION of distributed VeriSimDB instances, with configurable drift policies governing cross-instance consistency.

2. Concept Comparison

Concept	VCL	SQL
Column/Field Selection	SELECT with modalities: GRAPH, VECTOR, TENSOR, SEMANTIC, DOCUMENT, TEMPORAL, PROVENANCE, SPATIAL, or * (all eight). Modalities can be combined: SELECT GRAPH, VECTOR, SEMANTIC.	SELECT with column names or * for all columns.
Data Source	FROM STORE <name>, FROM HEXAD <uuid>, or FROM FEDERATION <name>. A STORE is a collection of octad entities. HEXAD names a single octad entity addressed by UUID — it is the legacy keyword for the octad source, retained for backward compatibility from when the entity had six modalities rather than eight. A FEDERATION spans multiple VeriSimDB instances.	FROM <table> or FROM <table> AS <alias>. Tables are flat relational structures.
Filtering	WHERE supports field conditions (h.field = value) and full-text predicates: CONTAINS(h.content, "term") for substring matching, MATCHES(h.content, "pattern") for pattern matching. Graph traversal uses Cypher-inspired syntax: (h)-[:EDGE_TYPE]→(target). Vector similarity uses SIMILAR TO […​].	WHERE supports standard comparison operators, LIKE, IN, BETWEEN, IS NULL, boolean combinators (AND, OR, NOT), and subqueries.
Joins	No JOINs. Graph modality replaces relational joins entirely. Relationships are first-class: (h)-[:CITES]→(target) traverses edges without explicit join syntax. Cross-modal correlation is implicit within a octad.	JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN, CROSS JOIN with ON conditions.
Mutations	Legacy SQL-shaped forms exist (INSERT HEXAD WITH …, UPDATE HEXAD <uuid> SET …, DELETE HEXAD <uuid>), each with an optional PROOF clause. The preferred path is the Octad API: POST /api/octads (create), PUT /api/octads/:id (update), DELETE /api/octads/:id (delete). This ensures cross-modal consistency.	INSERT INTO, UPDATE …​ SET, DELETE FROM, MERGE, TRUNCATE.
Verification	PROOF <type>(<contract>) clause requests a verifiable guarantee about the result. Six proof types, as defined by spec/grammar.ebnf: EXISTENCE, CITATION, ACCESS, INTEGRITY, PROVENANCE, CUSTOM. No SQL equivalent exists.	No equivalent. SQL has no mechanism for cryptographic or type-theoretic verification of query results.
Pagination	LIMIT n and OFFSET n work identically to SQL.	LIMIT n and OFFSET n (or vendor-specific: TOP, FETCH FIRST).

3. SQL Features: What VCL Has and Lacks

VCL is intentionally minimal. The table below records the actual status of each SQL feature against spec/grammar.ebnf v3.0.

Note

Four rows in this table — GROUP BY, ORDER BY, aggregate functions and HAVING — previously read "Not supported". They are supported: the grammar defines group_by_clause, order_by_clause, having_clause and aggregate_func = 'COUNT' | 'SUM' | 'AVG' | 'MIN' | 'MAX'. Those claims were correct for VCL v1.0 and were left behind when v2.0 added them; the correction closes item 1 of the known-inconsistencies list in VCL-SPEC.adoc. The remaining rows are genuinely absent from the grammar.

SQL Feature	VCL Status
Supported (group_by_clause). See VCL-SPEC.adoc §Aggregation.	Supported (order_by_clause, with ASC/DESC). In its absence, ordering falls back to the modality store — vector similarity ranking, graph traversal order, or temporal chronological order.
Supported (`aggregate_expr = count_all	aggregate_field`; `aggregate_func = 'COUNT'
'SUM'	'AVG'
'MIN'	'MAX'`).
Subqueries	Not supported. Queries are flat. Compose results in application code or use the Elixir query router for multi-step workflows.
DISTINCT	Not supported. Octad entities are inherently unique (UUID-addressed), so deduplication is rarely needed.
Supported (having_clause = 'HAVING', condition ;), used with GROUP BY.	UNION / INTERSECT / EXCEPT
Not supported. Use multiple queries and combine results application-side.	CREATE TABLE / DDL
Not supported. Schema is managed through the AffineScript registry (src/registry/) and the Elixir SchemaRegistry.	Window functions (ROW_NUMBER, RANK, OVER)
Not supported.	Stored procedures / triggers

4. What VCL Has That SQL Lacks

VCL Feature	Description
PROOF clause	Requests a verifiable proof certificate alongside query results. Six proof types (EXISTENCE, CITATION, ACCESS, INTEGRITY, PROVENANCE, CUSTOM) cover entity presence, citation-chain validity, access rights, tamper-evidence, verifiable lineage, and custom ZKP contracts. Enables dependent-type verification via the VCL-DT path.
Multimodal SELECT	Select specific modalities (GRAPH, VECTOR, TENSOR, SEMANTIC, DOCUMENT, TEMPORAL) or all (*). No SQL equivalent for querying fundamentally different data representations of the same entity.
FEDERATION queries	Target distributed VeriSimDB instances: FROM FEDERATION <name>. Includes drift policies that govern how cross-instance consistency is enforced during query execution.
Drift policies	DRIFT POLICY <name> attaches consistency enforcement rules to federated queries. Drift detection and repair are first-class query concerns.
Octad entity addressing	FROM HEXAD <uuid> addresses a single cross-modal entity by its UUID. All six modalities are accessible through one query against one identifier.
Graph traversal syntax	Cypher-inspired patterns directly in WHERE: (h)-[:RELATES_TO]→(target). No need for separate graph query language or JOIN emulation.
Vector similarity	WHERE h.embedding SIMILAR TO [0.1, 0.2, …​] performs nearest-neighbor search natively. SQL requires extensions (pgvector) or external systems.
Full-text predicates	CONTAINS(h.content, "term") and MATCHES(h.content, "pattern") are built-in, backed by the Tantivy-powered document store.

5. Example Comparisons

5.1. Retrieving an Entity

SQL:

SELECT *
FROM entities
WHERE id = '550e8400-e29b-81d4-a716-446655440000';

VCL (Slipstream):

SELECT *
FROM HEXAD 550e8400-e29b-81d4-a716-446655440000

The VCL version returns all eight modalities for that octad. The SQL version returns only the columns in the entities table.

5.2. Finding Related Entities

SQL (requires JOIN):

SELECT e2.*
FROM entities e1
JOIN relationships r ON e1.id = r.source_id
JOIN entities e2 ON r.target_id = e2.id
WHERE e1.id = '550e8400-e29b-81d4-a716-446655440000'
  AND r.type = 'CITES';

VCL (graph traversal):

SELECT GRAPH
FROM HEXAD 550e8400-e29b-81d4-a716-446655440000
WHERE (h)-[:CITES]->(target)

VCL eliminates the triple-table JOIN pattern entirely. Graph relationships are native.

5.3. Full-Text Search

SQL (PostgreSQL example):

SELECT *
FROM documents
WHERE to_tsvector('english', content) @@ to_tsquery('quantum & computing');

VCL:

SELECT DOCUMENT
FROM STORE research_papers
WHERE CONTAINS(h.content, "quantum computing")
LIMIT 20

5.4. Similarity Search

SQL (requires pgvector extension):

SELECT *, embedding <-> '[0.1, 0.2, 0.3, 0.4]' AS distance
FROM entities
ORDER BY embedding <-> '[0.1, 0.2, 0.3, 0.4]'
LIMIT 10;

VCL:

SELECT VECTOR
FROM STORE research_papers
WHERE h.embedding SIMILAR TO [0.1, 0.2, 0.3, 0.4]
LIMIT 10

5.5. Verified Query (No SQL Equivalent)

VCL-DT (dependent type path):

SELECT *
FROM HEXAD 550e8400-e29b-81d4-a716-446655440000
PROOF INTEGRITY(DataIntegrityContract)

This returns the octad data plus a cryptographic proof certificate asserting data integrity. SQL has no mechanism for this.

6. Summary

Capability	SQL	VCL
Relational queries	Yes	No
Multimodal queries	No	Yes
Mutations (INSERT/UPDATE/DELETE)	Yes	Legacy forms; Octad API preferred
JOINs	Yes	No (graph modality)
Aggregation (GROUP BY, COUNT, SUM)	Yes	Yes
Subqueries	Yes	No
PROOF verification	No	Yes
Federation with drift policies	No	Yes
Graph traversal	No (or extensions)	Yes (native)
Vector similarity	No (or extensions)	Yes (native)
Full-text search	Extensions	Yes (native)
Ordering (ORDER BY)	Yes	Yes
Pagination (LIMIT/OFFSET)	Yes	Yes

VCL is not a replacement for SQL. It is a purpose-built query language for a multimodal database that treats entities as eight simultaneous modal representations (an octad) rather than rows in flat tables. Use SQL when you need relational algebra. Use VCL when you need to query across modalities with optional formal verification.