MariaDB schemas, compatible with the MySQL dialect and generated with MariaDB-specific DDL. Open any of them in the free drawDB editor and export ready-to-run MariaDB DDL — tables, keys, indexes and comments.
43 schemas here, from 10 to 14 tables (531 tables and 4447 columns in total), written for PostgreSQL, MySQL. Each one ships an ER diagram you can open and edit, a column-by-column reference, design notes explaining the trade-offs, and SQL for all six dialects. Recurring themes across the set: scheduling, inventory, catalog, messaging, moderation.
How a calendar app models its data: calendars and sharing, events with their own time zones, RRULE recurrence with exception dates and per-occurrence overrides, attendees and RSVP, reminders, working hours and a free-busy index.
A vehicle rental schema: branches, vehicle classes versus the individual cars behind them, a per-branch availability calendar, reservations and signed agreements, mileage and fuel, damage inspections with photos, protection add-ons and one-way fees.
Outpatient scheduling in MySQL: recurring availability templates that generate slots, appointments that consume exactly one slot, waitlists that backfill cancellations, two-way reminders, referrals, and a dated no-show policy.
How a community chat platform models its data: servers with nested channels, roles carrying permission bitfields, three-state per-channel overwrites, per-server nicknames, messages and threads, reactions, attachments, invites and voice sessions.
How a food delivery marketplace models its data: restaurant menus built from reusable modifier groups, orders that snapshot every chosen option, courier dispatch offers, live location tracking, and the fee split between restaurant, courier and platform.
A production-shaped e-commerce schema: products with variants, inventory per location, carts, orders with snapshotted line items, payments and shipments. Open it in the editor or export SQL for six dialects.
How a webmail service models its data: labels applied many-to-many instead of IMAP folders, one stored copy per message, conversation threading, attachments deduplicated by content hash, delivery filters, drafts, read state, spam scoring and quota.
How an error monitoring service models its data: projects and releases, raw events with stack frames and breadcrumbs, grouping into issues by fingerprint, resolve and regression detection, alert rules and event sampling.
How a tournament platform models competition: single and double elimination, round robin and Swiss stages, teams with roster locks, a bracket stored as a node tree, best-of series with per-map results, venues and prize distribution.
How a handmade marketplace models its data: shops and sections, made-to-order listings with variations and personalisation, cross-shop carts, orders split per shop, shipping profiles and photo reviews.
How a social network models its data: symmetric friendships stored as one canonical row, posts with audience scoping, typed reactions, groups with membership roles, pages, and events with RSVPs.
How a feature management platform stores its data: flags and variations, per-environment settings, ordered targeting rules, reusable segments, percentage rollouts with deterministic bucketing, scheduled changes and a full audit trail.
The phpBB and Discourse shape rather than the Reddit one: curated categories and boards, threads bumped by replies, flat numbered posts with quoting, reputation and badges, a report-driven moderation queue and private messages.
How a book cataloguing site models its data: works split from editions and ISBNs, contributors with roles, default and custom shelves, reading progress, ratings and reviews, series ordering and a friend activity feed.
How an online supermarket models its data: per-store catalogue and pricing, weight-priced items billed on what was actually picked, baskets, substitution preferences and real substitutions, picking tasks, capacity-limited delivery windows and inventory counts.
A reservation system that actually handles availability: room types versus rooms, rate plans, a per-night rate and inventory calendar, reservations broken down by night, payments and verified reviews.
How a photo-sharing app models its data: asymmetric follows with pending requests for private accounts, posts carrying an ordered carousel of media, likes and two-level comments, stories that expire, saved collections and direct messages.
How a freelance and small-business invoicing app models its data in MySQL: clients and projects, tracked time, invoices with per-line tax, partial payments, credit notes, recurring templates, reminder schedules and multi-currency with the rate snapshotted at issue.
An internal service desk modelled properly: a service catalogue, incidents and requests, ordered approval chains, change requests with risk and rollback plans, linked assets, versioned knowledge base articles, SLA clocks that pause, and satisfaction ratings.
How a public library models its data: works, editions and barcoded copies, branches and holdings, members, loans with renewals, a positioned hold queue, fines and payments, and inter-branch transfers.
How a professional network models its data: profiles with a date-ranged career history, symmetric connections created from invitations, canonical skills with endorsements, company pages, job postings and applications, and a feed.
How a video streaming service models its data: films and series in one titles table, seasons and episodes, profiles inside an account, resume positions, per-region licensing windows, My List, ratings and subtitle tracks.
How a docs-and-databases workspace models its data: nested pages, a document stored as an ordered block tree, user-defined databases whose rows are pages, views with filters and sorts, inherited permissions and block-anchored comments.
How a package manager backend stores its data: packages and immutable published versions, integrity hashes, dependency ranges, movable dist tags like latest and beta, owners and scoped access tokens, download rollups, deprecations and yanks.
How a dispensing pharmacy models its data: a drug catalogue by strength and form, stock held as batches with expiry dates picked first-expired-first-out, dispense events, interaction and allergy checks, insurance claims and a controlled-drugs register.
How a visual bookmarking app models its data: images deduplicated by content hash, pins as saves rather than uploads, repins as a self-reference to the source pin, boards with sections and collaborators, follows of both people and boards, and saved searches.
A quiz engine that handles four question types at once: reusable question banks, draw rules and randomised papers, typed answer keys, per-question responses, partial credit, negative marking and time limits.
How a forum models its data: subreddits and subscriptions, link and text posts, arbitrarily deep comment trees stored as materialised paths, narrow vote tables, karma, flairs, and an append-only moderation log with removal reasons.
How a dining-room POS models its data: floor plan tables and seats, open checks, courses and fire times, kitchen tickets routed per station, sold-out items, split checks, cashier shifts and tip-outs.
How an in-store point of sale is modelled: stores and registers, cashier shifts with opening float and closing count, sales with discounted lines, multi-tender payment, returns against the original sale, drawer movements and approved price overrides.
Courses versus sections, terms, enrolments that carry the final grade, prerequisites as a self-join, assignments with weights, per-attempt submissions and idempotent attendance registers.
How a team chat product models its data: workspaces and per-workspace identity, public private and shared channels, a read cursor per member instead of a read flag per message, thread replies, mentions, files, saved items and installed apps with granted scopes.
How a music streaming service models its data: artists, albums and tracks, credited roles on a track, ordered playlists with collaborators, saved library, offline downloads and an append-only play log.
How a fitness tracking app models its data: activities with compressed sensor streams instead of one row per second, segments and segment efforts with materialised leaderboards, personal records, kudos and comments, clubs, gear mileage and training load.
How a virtual care product models its data: clinician licences per state with expiry dates driving who may treat whom, bookable slots, video consultations with a waiting room, intake forms, e-prescriptions routed to a pharmacy, and per-region pricing.
How a short-video app models its data: sounds as first-class rows reused across videos, duets and stitches as self-references, an append-only watch-event log feeding a recommendation feed, plus follows, likes, comments and hashtags.
How a dating app models its data: profiles with ordered photos, discovery preferences, an append-only swipe log, matches created only on a mutual right swipe, messaging scoped to a match, blocks and reports, and consumable boosts and super likes.
How a kanban board app models its data: boards, lists and cards with fractional positions, labels, checklists and check items, card members and watchers, attachments and covers, power-ups, templates and an activity feed.
How a live streaming platform models its data: broadcast sessions with start and end times, VODs and clips derived from them, tiered and gifted subscriptions, bits, chat, moderation logs and raids.
How a microblogging platform models its data: one tweets table covering tweets, replies, retweets and quotes, an asymmetric follow graph, a fanned-out home timeline, lists, bookmarks, and hashtags and mentions extracted at post time.
How a mobile messenger models its data: accounts keyed by phone number, linked devices, private contacts, direct and group chats as one entity, messages with media and replies, per-recipient delivery and read receipts, and disappearing messages with a TTL.
How a video platform models its data: channels and uploads, encoded renditions, view counts rolled up per day, likes, one-level comment threads, subscriptions, playlists, monetisation and community posts.
How a video meeting platform models its data: accounts and assigned licences, a meeting series separated from its materialised occurrences, registrations, participant join and leave intervals, breakout rooms, recordings, in-meeting chat and waiting room admissions.