Ridge Compatibility and Limits

Ridge uses familiar relational SQL and a PostgreSQL-wire transport while retaining its own storage, catalog, type, planner, operational, and security contracts.

Compatibility matrix

Capability	Ridge v0.3
Embedded database	Yes
Native loopback server	Bounded pgwire
Relational SQL	Bounded documented surface
MVCC	Persistent read committed and repeatable read
Concurrent writes	Disjoint staging/publication with conflict validation
PostgreSQL drivers	Frozen client and query subset
PostgreSQL catalogs	No broad compatibility
MySQL-like introspection	Ridge-native `SHOW` and `DESCRIBE` aliases
Replication or sharding	Not implemented

Unsupported or intentionally deferred

replication, failover, sharding, rebalancing, and distributed SQL;
distributed transactions;
triggers, stored procedures, extensions, and recursive CTEs;
partial or expression indexes and general window frames;
COPY, SCRAM, certificate identity, general binary formats;
broad pg_catalog and information_schema;
unrestricted ORM migration or schema-discovery compatibility;
public network exposure of ridged or Ridge Admin;
Windows Ridge Admin packaging and service installation.

Bounded means exact

Limits are part of the API, not suggestions. Queries, rows, messages, plans, work memory, spill, tabs, histories, profiles, exports, and maintenance operations reject overflow explicitly. Consult the current capability and release documents for numeric limits.

Performance claims

Published benchmarks identify the host, engine versions, durability settings, warmup, sample count, workload, correctness checks, and raw artifacts. They are regression baselines only. Do not generalize the one-million-operation or focused concurrency numbers to another schema, machine, durability policy, or fleet.

Porting guidance

Inventory application SQL and driver startup behavior.
Replace PostgreSQL catalog introspection with Ridge SHOW commands.
Test schema migration and every prepared query against a real ridged.
Verify transaction and retry behavior, especially uncertain commits.
Keep unsupported features behind explicit application alternatives.
Run differential fixtures for business-critical semantics.