Tablekeeper: Double-Booking Is Impossible

Reservation systems double-book by accident — two guests, one table, an apology email. Tablekeeper moves the guarantee out of application code into the database: overlapping bookings on the same table cannot be committed, no matter what the app does. No retry storm, race, or buggy deploy can beat the storage engine's refusal. The whole guarantee is one partial exclusion constraint: EXCLUDE USING gist ( table_id WITH =, tstzrange(starts_at, ends_at, '[)') WITH && ) WHERE (status IN ('held','confirmed')) The half-open '[)' range keeps it honest: a booking ending 19:00 and one starting 19:00 don't overlap — back-to-back seatings work like a real restaurant. As strict as reality, not stricter. Proven live, not in slides: /kill-demo fires 50 real concurrent HTTP requests at one table. Verdict, every time: 1×201 CREATED, 49×409 SLOT_TAKEN. A 12-way stampede sharing one idempotency key yields one reservation; a reused key with a different payload is refused 422. Every push runs an adversarial suite: 50-way races, hold expiry, cancel-vs-confirm, DST boundaries, soak — 28/28 green on embedded Postgres and postgres:16. A separate 9-probe red team attacks the live HTTP surface: RED TEAM FAILED TO BREAK IT, zero 5xx. This is Dark Factory: a band of coding agents built the product, and the factory checks itself. ShipScore, our open-source gate, scores Design/Ship/Run/Secure/Test and blocks merges below threshold — 100/100 (A) from day one, after honestly failing our first run until we fixed the bug it caught. The product is real: TTL holds with countdown, idempotent-replay button in the UI, guest self-cancel that frees the slot instantly, DST-aware service hours, append-only audit trail. One dialect, two engines: PGlite (embedded Postgres 17) locally, serverless Postgres (Neon) in production. Next.js 16 + TypeScript + Vercel. Paste one connection string — double-booking becomes impossible for you too.