Current limitations

The current technical boundaries of OpenSya Persistence.

OpenSya Persistence is an early-stage runtime that powers OpenSya and can be used in any TypeScript application. Its core execution model is usable, but the following boundaries remain intentional.

Schema lifecycle

Persistence does not generate or apply migrations. buildTable() constructs runtime Drizzle tables only. Keep physical schema changes in a migration tool.

Database support

Only the Drizzle PostgreSQL adapter is included. Introspection targets the public schema and does not reconstruct foreign keys, relations, defaults, check constraints or detailed PostgreSQL type parameters.

Relations

Population is explicit and direct. Nested paths, relation-specific filtering, sorting, pagination and projections are not implemented. Relation metadata is not inferred from PostgreSQL foreign keys.

Static query inputs

Registered table names and returned entities are inferred. Filter field names, operator values and creation/update inputs are still represented by generic query structures rather than fully table-specific input types.

json columns infer as unknown; applications must narrow or explicitly type their domain JSON shape.

Cursor pagination

Only forward first/after pagination is available. Backward pagination is not implemented, and values used in cursor ordering cannot be null.

Authorization and tenancy

The engine carries user, tenantId and arbitrary context, but does not yet enforce operation policies, row-level authorization or mandatory tenant filters.

Delivery semantics

The Domain Event outbox provides at-least-once delivery. Consumers must be idempotent. Persistence supplies the processor contract but no Kafka, RabbitMQ, Redis or webhook transport.

Hooks and validation

  • reads have no lifecycle hooks;
  • after-delete hooks do not receive deleted entities;
  • update-many transforms one patch and runs after-update per returned entity;
  • partial updates do not rediscover invalid untouched fields;
  • application validators do not replace database constraints for concurrent invariants.
Review the changelog before upgrading and run the production playground against PostgreSQL for every release candidate.