Why KRI's Booking Schema Avoids a Database Constraint to Prevent Double-Booking

A common approach to stopping double bookings in PostgreSQL is an EXCLUDE constraint, but the author's booking SaaS for beauty businesses needs a different rule. Client bookings must not overlap any live booking for the same specialist, while owner-made bookings may deliberately overlap, which an order-dependent rule like this cannot express with a plain UNIQUE or EXCLUDE constraint. The schema therefore drops the UNIQUE constraint and relies on an application-level transaction to enforce the client-facing guard. That transaction now catches partial overlaps that the old constraint missed, such as a 60-minute service overlapping a booking that starts 30 minutes later. The trade-off is that any write bypassing this transaction now lacks a database-level safeguard.}