When the Application Layer Is Disposable: Putting Integrity Constraints Back in the Database

1 INTRODUCTION

• Most major database systems support only a limited set of built-in constraints, while complex multi-table enforcement has high, unpredictable costs.Triggers and shadow tables can implement complex constraints, but their enforcement has largely migrated to application layers.Source: §1 · p. 1
• Higher-level mappings fragment conceptual constraints across relations, and disposable LLM-generated writers may bypass application code that previously maintained invariants.The paper argues that the database should provide durable constraint specifications and enforcement independent of individual writers.Source: §1 · p. 1
• The proposed constraint governor manages constraints from declaration or discovery through validation, enforcement, revision, and removal.It tracks constraint status and chooses the enforcement mechanism, enforcement point, failure action, and feedback to writers.Source: §1 · p. 1
• A compiler translates the governor’s decisions into enforcement structures and operations, including their maintenance, synchronization, and recovery.The decisions may change as candidate constraints are provisionally checked, promoted to blocking enforcement, revised, or dropped.Source: §1 · p. 2
• Up to 2.41× at 256 concurrent clients, constraint indexes outperform the best baselines across evaluated workloads.The workloads include constraints from distributed inheritance hierarchies, folded relationships and weak entities, cardinality bounds, and functional dependencies.Source: §1 · p. 2

2.1 Constraints from Higher-level Conceptual Models

• Concrete-table mappings turn hierarchy-wide entity keys and uniqueness, some referential-integrity rules, cardinality bounds, functional dependencies, and folded weak-entity identity into constraints spanning relations or embedded values.These constraints are not directly expressed by ordinary keys, foreign keys, and row-level CHECK constraints in the described cases.Source: §2.1 · pp. 2–3
• A property-graph key can depend on membership and moderator edges across separate relations, so adding a forum’s first member can create a uniqueness violation without changing moderator assignments.A UNIQUE constraint on moderator identifiers alone would also restrict forums without members, imposing a stronger condition.Source: §2.1 · p. 3

2.2 LLM-Driven Writers and Constraints

• The probe tested six constraints with two models, five generations per model, both without constraints and with all six stated explicitly.Scenarios covered shared identifiers and email across specializations, an advisor fan-out cap, and the functional dependency role →access_profile.Source: §2.2 · p. 3
• 60/60 trials without explicit constraints produced unchecked INSERT or UPDATE statements that would silently violate intended invariants; prompted responses still varied in their failures.With constraints supplied, the SQL became more complex and varied, but correct enforcement remained unreliable.Source: §2.2 · pp. 3–4
• 40/60 prompted trials used silent restrictions, 15/60 used check-then-raise, and 4/60 still provided no guard.Silent restrictions may affect zero rows without an error or constraint-specific feedback; check-then-raise can remain vulnerable to concurrency races.Source: §2.2 · pp. 3–4

3 BACKGROUND

• Existing relational systems efficiently enforce uniqueness and referential integrity, but broader constraint classes are rarely supported directly and multi-relation access paths are missing.EXCLUDE constraints use a GiST-backed access path but are confined to one relation.Source: §3 · p. 4

3.1 Triggers

• Trigger checks can miss concurrent duplicate inserts under READ COMMITTED, requiring SERIALIZABLE transactions with retries or explicit locking of conflicting conceptual keys.Trigger queries also repeat on relevant writes and require custom maintenance as schemas and mappings evolve.Source: §3.1 · p. 4

3.2 Shadow Tables

• Shadow tables turn multi-relation uniqueness into local indexed constraints, but require transactional maintenance and constraint-specific structures beyond uniqueness.Adding constraints requires schema changes and backfills; native materialized views require explicit refreshes and lack automatic incremental maintenance.Source: §3.2 · pp. 4–5

3.3 Prior Work

• Prior work covers conceptual constraint languages, incremental validation, view maintenance, and concurrency coordination, but validation alone does not ensure correctness under concurrent updates.Constraint discovery tools could supply candidate constraints to a governor.Source: §3.3 · p. 5
• The paper frames constraint indexes as one mechanism within dynamic constraint governance, which chooses how and when constraints are enforced and how violations are handled.The framework also tracks how those choices evolve.Source: §3.3 · p. 5

4.1 Constraint Governor

• The governor selects each constraint’s mechanism, enforcement point, failure action, and writer feedback, while constraints can move from provisional alerts to blocking enforcement, demotion, or removal.Transactional deployments can prevent violating commits; disaggregated monitors instead observe updates and may alert, quarantine data, prevent downstream publication, or initiate repair.Source: §4.1 · p. 6

4.2 Constraint Indexes

• Constraint indexes consolidate identity, uniqueness, and owner state into shared lookup paths, enforcing folded weak-entity constraints without scanning embedded values while relations remain the durable data source.The identity and unique-value indexes enforce weak-entity identity and card-number uniqueness; the owner index groups dependent objects for deletion and cascading maintenance.Source: §4.2 · p. 6

4.3 Compilation

• For each constraint domain, compilation specifies auxiliary state, maintenance operations, logical locks, undo actions, and reconstruction from durable relations.The prototype implements these components by hand with constraint-specific templates; automatic compilation from a conceptual schema and relational mapping remains future work.Source: §4.3 · pp. 6–7

4.4 Transactional Maintenance

• Updates lock affected conceptual keys, validate and reserve auxiliary state before relational changes, then commit or undo; correctness assumes every relevant write uses these operations.Monitoring-only deployments must also represent violating data in their auxiliary state, an adaptation left for future work.Source: §4.4 · p. 7

5.2 Transaction Integration and SQL Interface

• Updates acquire transaction-scoped advisory locks for affected conceptual values, mutate constraint indexes, and journal inverse operations for abort recovery.Locks are acquired in deterministic order; commit discards the journal, while abort replays it in reverse order.Source: §5 · p. 7, §5.2 · pp. 8–9

5 POSTGRESQL PROTOTYPE

• The prototype assumes relevant writes invoke hand-written constraint-index operations in the same transaction as relational updates and does not intercept direct SQL bypasses.The relational representation remains the durable source of truth, and the derived indexes can be rebuilt after a server restart.Source: §5 · p. 7, Figure 4 · p. 8

5.1 Shared-Memory Organization

• Each logical index uses partitioned shared-memory hash tables with per-partition lightweight locks, allowing operations on different partitions to proceed concurrently.Each constraint domain can maintain separate partition arrays for its logical indexes.Source: §5.1 · p. 7, Figure 5 · p. 9

5.2 Transaction Integration and SQL Interface

• SQL-callable operations reserve, require, update, and remove conceptual identities, while cardinality operations validate endpoints and bounds before changing counts.Reservations and relational mutations run in the same transaction; whole-transaction abort restores auxiliary state, while savepoint rollback needs additional handling.Source: §5.2 · pp. 8–9

5.3 Recovery

• Constraint indexes are derived, non-durable structures rebuilt by scanning participating relations after recovery; reconstruction fails if it finds a duplicate violating a constraint.Normal execution avoids persistent tuples, buffer management, WAL logging, and persistent index maintenance for constraint state.Source: §5.3 · p. 9

• The evaluation covers constraints across inheritance hierarchies, folded relationships, and folded weak entities, plus a composed end-to-end workload.The prototype is a PostgreSQL extension whose SQL-callable function boundaries, general-purpose advisory locks, and lack of planner and executor integration could be addressed by native integration.Source: §6 · pp. 9, 11
• Constraint indexes retain 81.4%–98.7% of unconstrained throughput across key-oriented workloads, with retention lowest when an operation maintains several structures.The IdCard operations maintain composite identity, unique card-number, and owner-to-dependent indexes.Source: §6 · p. 10
• 1.09×–1.38× improvement over the best trigger or shadow-table baseline across key-oriented workloads when constraint indexes enforce all evaluated constraints.For single-relation Belongs_to inserts, constraint indexes reach 82.7K TPS versus 68.0K TPS for the hybrid configuration, a 1.22× throughput comparison.Source: §6 · pp. 10–11
• 2.41× improvement over the strongest alternative, retaining 95.9% of unconstrained throughput, for two-sided contributes_to cardinality inserts.For Student inserts with role → access_profile, the reported improvement is 1.47× over the strongest alternative, with 93.2% of unconstrained throughput retained.Source: Figure 6 · p. 11, §6 · p. 11
• Query-based checking reaches 5.3K TPS for IdCard insertion versus 32.9K TPS with constraint indexes, and unsynchronized query and trigger checks remain vulnerable to write skew.The query and query-trigger baselines run at READ COMMITTED and are not sound in several evaluated cases; stronger synchronization costs were not measured.Source: §6 · p. 11
• 44.4K TPS versus 37.1K for relational enforcement and 52.6K without constraints yields a 1.20× improvement and 84.3% throughput retention in the end-to-end workload.The workload composes hierarchy identity and email uniqueness, folded-relationship and weak-entity constraints, and cascading deletions.Source: §6 · p. 11

7 CONCLUSION & RESEARCH CHALLENGES

• Constraint indexes compile a substantial class of conceptual-model constraints into transactional access paths at low enough cost to leave switched on.The authors argue that enforcement structures should be treated as physical design and selected alongside the relational schema.Source: §7 · pp. 11–12
• Automating and generalizing constraint-index construction requires incremental auxiliary-state maintenance; arbitrary assertions needing unrestricted query evaluation may remain outside the approach.The authors identify conditional uniqueness, participation constraints, interval disjointness, and other aggregate conditions as open directions.Source: §7 · p. 12
• Constraint governance must choose enforcement mechanisms and timing, and allow inferred constraints to be provisionally deployed, promoted, demoted, or dropped as evidence changes.Open questions include evaluating promotion evidence, handling existing violations, and keeping provisional enforcement proportional to uncertain constraint value.Source: §7 · p. 12
• Writers need transaction testing and rejection feedback identifying both the violated constraint and conflicting values; constraint descriptions alone produced divergent, frequently unsafe code.The authors conclude that databases must provide semantic context and enforcement independent of writer behavior.Source: §7 · p. 12