A complete dating application database schema inspired by platforms like Tinder, Bumble, or Hinge. Includes user accounts with rich profiles (photos, interests, about me), configurable matching preferences (age range, distance, gender), swipe-based matching system with mutual match detection, and in-app messaging between matched users. Suitable for building modern dating applications or social discovery platforms.
matches stores every swipe, not only the successful ones. Each row is one person's action on another, and is_mutual marks the moment the second row arrives and the pair becomes a match. Storing the passes as well is what stops the same profile being shown again, which is the other half of what a swipe means.
Messages hang off the match, not off the two users. messages.match_id means a conversation cannot exist without the mutual action that permitted it — unmatching removes the right to message by removing the parent, and no separate check is needed at send time.
Preferences and profile are deliberately different tables. profiles holds what someone is, including location_lat and location_lng; preferences holds what they are looking for — an age range, a distance limit, a gender preference. Candidate selection is the intersection of one person's preferences with another's profile, run in both directions.
Keeping only mutual likes would make the table far smaller and break the product: without the passes there is no record of who has already been shown, so the same profiles reappear forever. The cost is the largest table in the app by a wide margin, which is why it is usually partitioned or aged out — a pass from two years ago has little value.
Whether a match exists is derivable by looking for the opposite row, and doing that on every list render is a self-join on the biggest table in the database. The flag is written when the second swipe lands, making the match list a simple filtered read. Both rows must be updated together, and that write is the one place this design can go wrong.
location_lat and location_lng are portable across databases and readable in any client. The honest limitation is that distance filtering on plain numbers cannot use a spatial index — a bounding box narrows it, but a real deployment moves to a geography type or a geohash column. This schema shows where the data lives, not how to make the search fast.
A block is immediate, unilateral and needs no review. A report is a claim that someone else must assess, which is why it carries a reason, a description and a status. Merging them would give blocking a workflow it does not need, and would leave reports with no way to express that nobody has looked at them yet.