Social network, built on every verified stack.
Social network: public profiles with @-handles, a directed follow graph, an authored-post feed, and per-post like edges.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What Social network gives you
Better Auth's user row is the account; profiles is the face that account shows. The split is deliberate: profiles.user_id is a unique text FK, so the mapping is strictly one-to-one, but posts.author_id, follows.follower_id, follows.following_id and post_likes.user_id all reference user.id rather than profiles.id. Authorship is keyed to the account, while the handle, bio and avatar are a separate row you join in for display. Every one of those FKs cascades on delete, so removing an account clears its profile, both directions of its follow edges, its posts and its likes in a single statement — there is no orphan sweep to write. The graph itself is two edge tables, and both make the edge its own identity.
follows has no surrogate key: (follower_id, following_id) is the primary key, and follows_follower_following_unique restates the same rule. You cannot follow the same account twice, and direction matters — following back inserts a second, separate row. post_likes is shaped identically, with (post_id, user_id) as the composite primary key plus post_likes_post_user_unique. Neither table caches a count; follower totals and like totals are aggregates over the edges themselves. The cost of that shape is worth knowing before you build on it. A home feed is fan-out-on-read: take the follower-side prefix of the follows primary key to get everyone a viewer follows, then read each author through idx_post_author.
posts carries only idx_post_author — no (author_id, created_at) composite and no index on created_at alone — so newest-first ordering is a sort on top of the index hit, which is fine at seed scale and the first thing to revisit under load. Likes read better: (post_id, user_id) leads with post_id, so counting a post's likes and answering whether the current viewer already liked it both ride the same key, and idx_post_likes_user runs the relation backwards for a liked-posts page. handle is unique and separately covered by idx_profile_handle, which is what keeps an /@name route a single-row lookup.
Built for
profiles.handle is unique and separately covered by idx_profile_handle, so the URL segment is a single-row hit; profiles.user_id is a unique FK to user.id, making the hop between profile and account 1:1 in either direction.
idx_follow_following exists for the reverse direction of the edge: listing or counting everyone whose follows.following_id points at a user, without scanning the follow table.
The follows primary key is (follower_id, following_id), so everyone a viewer follows is a prefix scan of the key itself — no secondary index needed — and each author is then read through idx_post_author on posts.
idx_post_author narrows posts to one author_id. There is no (author_id, created_at) composite, so the newest-first ordering is a sort layered on the index hit rather than a range read.
post_likes is keyed (post_id, user_id): the leading column counts a post's likes, the full key answers the viewer's own like as a point lookup, and idx_post_likes_user inverts it into that user's liked-posts page.
Why Social network, specifically
Both the follow edge (follower_id + following_id composite PK + unique) and the like edge (post_id + user_id composite PK + unique) carry explicit unique constraints — the constraint is the identity, not just a performance index.
Better Auth's user.id is text, not uuid; all four tables match that type on their FK columns rather than recasting, so joins never cross a type boundary.