How I Built a Restaurant Waitlist App on Amazon Aurora DSQL That Literally Cannot Double-Book a Table

ekpenyongasuquo — Wed, 10 Jun 2026 06:15:37 +0000

I just shipped TableTurn — an affordable restaurant waitlist and table management system built on Amazon Aurora DSQL and Vercel. This post covers the core technical decision that makes it work: using Aurora DSQL's serializable distributed transactions to prevent double-booking at the database level.

I created this post as part of my entry for the H0: Hack the Zero Stack with Vercel v0 and AWS Databases hackathon. #H0Hackathon

The problem

12 million independent restaurants worldwide manage waitlists on paper or WhatsApp. Professional tools like OpenTable cost $300–700/month — unaffordable for most. TableTurn solves this for $29/month.

The database problem nobody talks about

Every table management system has this critical requirement: two hosts must never seat two different parties at the same table simultaneously. Most systems handle this in application code — checking availability before updating. But two requests arriving at the same millisecond can both pass the availability check before either updates the table status. The result: double booking.

Why Aurora DSQL solves this permanently

Aurora DSQL provides serializable distributed transactions — the strongest isolation level in SQL. Here is the actual seating transaction in TableTurn:


typescript
await sql.begin(async (tx) => {
  const table = await tx`
    SELECT id, status FROM tables
    WHERE id = ${table_id}
    FOR UPDATE
  `;

  if (table[0].status !== "available") {
    throw new Error("Table just taken by another host");
  }

  await tx`UPDATE tables SET status = 'occupied' WHERE id = ${table_id}`;
  await tx`UPDATE parties SET status = 'seated', table_id = ${table_id} WHERE id = ${id}`;
});

The FOR UPDATE lock inside a serializable transaction means Aurora DSQL orders these operations globally. One transaction completes before the other begins. Double booking is mathematically impossible — not just practically unlikely.
Aurora DSQL vs DynamoDB vs standard Aurora
I considered all three databases:
DynamoDB — eventual consistency cannot guarantee serializable ordering for concurrent writes
Aurora PostgreSQL — single-region, requires managing replication for multi-region
Aurora DSQL — distributed serializable consistency, serverless, no capacity planning
For TableTurn, Aurora DSQL was the only honest choice.
Three Aurora DSQL quirks I learned the hard way
CREATE INDEX requires ASYNC keyword — standard CREATE INDEX statements fail. Use CREATE INDEX ASYNC and Aurora DSQL returns a job_id and builds the index in the background.
IAM auth tokens expire every 15 minutes — implement token refresh logic in your connection layer or you will see access denied errors in production.
No foreign keys — enforce referential integrity at the application layer. Use TEXT for IDs to avoid UUID edge cases.
The result
Live demo: https://tableturn-steel.vercel.app
GitHub: https://github.com/ekpenyongasuquo/tableturn
Try seating two parties at the same table simultaneously — one succeeds, one gets "Table just taken by another host." Aurora DSQL makes that guarantee, not my application code.

**Tags field:** aws, vercel, nextjs, database

---

## LinkedIn — Copy everything below this line:

---

I just shipped TableTurn — a restaurant waitlist and table management system built on Amazon Aurora DSQL and Vercel, for the H0: Hack the Zero Stack hackathon. #H0Hackathon

The core insight: most table management systems have a race condition. Two hosts clicking "Seat" at the same millisecond can both confirm the same table — causing a double booking.

I solved this permanently using Aurora DSQL's serializable distributed transactions. The no-double-booking guarantee lives at the database level — not in application code.

Three things I learned building on Aurora DSQL:

1. CREATE INDEX requires ASYNC keyword — standard CREATE INDEX statements fail. Aurora DSQL returns a job_id and builds the index in the background.

2. IAM auth tokens expire every 15 minutes — you need token refresh logic in your connection layer for production use.

3. No foreign keys — referential integrity must be enforced at the application layer. Use TEXT for IDs to avoid UUID edge cases.

The result: a fully deployed working product at $29/month targeting 12 million independent restaurants that cannot afford OpenTable.

Live demo: https://tableturn-steel.vercel.app
GitHub: https://github.com/ekpenyongasuquo/tableturn

I created this post as part of my entry for the H0: Hack the Zero Stack with Vercel v0 and AWS Databases hackathon. #H0Hackathon

---

## Medium — Copy everything below this line:

---

**Title field:** Why I chose Amazon Aurora DSQL over DynamoDB for my hackathon project — and why it was the right call

**Body field:**

I am building TableTurn for the H0: Hack the Zero Stack hackathon — an affordable restaurant waitlist system built on Amazon Aurora DSQL and Vercel. This post explains exactly why I chose Aurora DSQL over DynamoDB and standard Aurora PostgreSQL.

I created this post as part of my entry for the H0: Hack the Zero Stack with Vercel v0 and AWS Databases hackathon. #H0Hackathon

## The requirement that drove the database choice

TableTurn has one non-negotiable requirement: no double bookings. Two hosts must never seat two different parties at the same table simultaneously — under any circumstances. This is not a UI problem. It is a database consistency problem.

## Why DynamoDB was wrong for this

DynamoDB is an excellent database for many workloads. But its consistency model for concurrent writes cannot provide the same guarantee as serializable SQL transactions for this specific pattern. A DynamoDB conditional write works in most cases — but under specific concurrent access patterns, two writers targeting the same item can create conflicts that require application-level retry logic. The guarantee is probabilistic, not absolute.

## Why Aurora DSQL was right

Aurora DSQL provides serializable transaction isolation — the strongest consistency guarantee in SQL. Two transactions attempting to update the same row inside a serializable transaction cannot interleave. One completes first. The other sees the committed state. This is the only database primitive that makes the no-double-booking guarantee absolute rather than probable.

## Three Aurora DSQL quirks to know before you build

1. No foreign keys — Aurora DSQL does not support foreign key constraints. Enforce referential integrity in your application layer. Use TEXT type for IDs.

2. CREATE INDEX ASYNC — Standard CREATE INDEX fails. Always use CREATE INDEX ASYNC which returns a job_id and builds the index in the background.

3. IAM token expiry — Aurora DSQL uses IAM authentication. Tokens expire every 15 minutes. Implement token refresh in your connection layer.

## The result

TableTurn is live at https://tableturn-steel.vercel.app

The seating transaction using Aurora DSQL's serializable isolation has been tested with concurrent requests — one succeeds, one returns "Table just taken by another host." Every time. Without exception. That is the power of choosing the right database primitive for the problem.

GitHub: https://github.com/ekpenyongasuquo/tableturn

---

## After publishing all three

Come back here with the three published URLs and I will tell you exactly where to paste them in your Devpost submission for the +0.6 bonus points.

DEV Community: ekpenyongasuquo

How I Built a Restaurant Waitlist App on Amazon Aurora DSQL That Literally Cannot Double-Book a Table

The problem

The database problem nobody talks about

Why Aurora DSQL solves this permanently