Video platform, built on every verified stack.
Video platform: user-owned channels with published videos, append-only view records, and ordered playlists.
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 Video platform gives you
Publishing here is channel-first. A channel belongs to one user and carries a globally unique handle, and everything else hangs beneath it: videos reference channel_id, playlists reference channel_id, and playlist_videos joins the two under a composite primary key on (playlist_id, video_id) with an explicit position column. No video carries an owner column of its own — a video's owner is whoever owns its channel, one FK hop away — which is why moving a channel between accounts moves its whole library without touching a single video row. video_views behaves unlike the rest of the schema. It is append-only: one row per watch event, watched_secs recording how far the viewer got, no unique constraint and no update path.
View counts and watch time are rollups over those rows rather than a maintained counter, so writes never contend on a hot column and the same person replaying a video produces two records instead of an increment. idx_view_video_time on (video_id, created_at) is what keeps that affordable: per-video analytics over a date window is a range scan. viewer_id is nullable and ON DELETE SET NULL, so signed-out playback is a first-class row and closing an account preserves the aggregate while dropping the attribution. What the indexes deliberately do not cover matters as much.
videos has idx_video_channel and a status CHECK over processing, published and private alongside a nullable published_at, but nothing indexes status or published_at — catalog reads are cheap channel by channel, and a cross-channel recently-published feed is a scan until you add that index. video_views has no index on viewer_id, so what a given person has watched is the expensive direction, and a real watch-history surface wants an index of its own. Playlist reads ride the primary key's leading column, and position is a plain integer with no uniqueness, so item order is a sort over a small set and two entries can legally claim the same slot.
Built for
idx_video_channel on videos.channel_id scans one channel's library, and the videos_status_check values (processing, published, private) filter unpublished rows out of the public view in the same pass.
idx_view_video_time on video_views (video_id, created_at) makes the rollup a range scan; watched_secs sums into total watch time and the row count is the view count.
channels.handle is notNull and unique, so the handle route is a single-row lookup and a collision is rejected by the database rather than checked in application code.
playlist_videos is keyed by the composite primary key (playlist_id, video_id); its leading column fetches one playlist's items, and the position column carries the creator's ordering.
video_views.viewer_id references user with ON DELETE SET NULL rather than CASCADE, so the watch rows and their watched_secs survive account deletion as anonymous events — unlike channels.owner_id, which cascades and takes the channel's videos and views with it.
Why Video platform, specifically
channels.handle carries a unique constraint — URL-safe handle collisions are caught at the DB layer, not in application code.
video_views is append-only (no update path, composite index on videoId + createdAt): aggregate view counts and watch-time stats by rolling up rows rather than maintaining a running total.