Full database schema for a YouTube-like video streaming platform covering user accounts, creator channels, video catalog with metadata, playlists, commenting system with threading, likes/dislikes, subscription management, watch history, notifications, channel monetization, ad break management, and community posts.
Accounts and channels are separate here. users is who signs in and what they watched; channels is what publishes. Splitting them is what lets one account own several channels and lets watch_history and likes belong to a person while videos and monetization belong to a channel.
watch_history is the unusual table. It is not a log of views — the count for that lives on the video — but one row per viewer per video holding last_position_seconds. That is the resume feature: it is a row that gets updated as you watch rather than appended to.
Likes and dislikes share one table with an is_like flag rather than two tables or two counters. A vote is one row per user per video, so changing your mind is an update and taking it back is a delete, and the invariant that a person votes once is a unique constraint rather than application code.
is_like on a single row per user per video means a unique constraint on (user_id, video_id) enforces one vote. Two tables would need a cross-table check to stop someone liking and disliking at once, and two counters would drift independently. Switching a vote is an update to a boolean.
A view log would be append-only and enormous, and answering 'where did I leave off' would mean reading the last row of many. One row per viewer per video, updated in place, makes resume a lookup. The cost is that you lose per-session history — which is a different feature, and if you need it, it is its own table rather than a change to this one.
subscriber_count, video_count and view_count are stored on channels because every video page shows the channel's subscriber count. Deriving it would mean counting subscriptions on each page view. As with all stored counters, the underlying table remains the truth and the number needs reconciling.
status carries upload, processing, published and private, because a video exists before it can be watched. published_at is separate so that scheduling is a timestamp rather than a state machine, and a video can be published, unlisted and re-published without losing its original date.