The right shape for a custom database (and three shapes to avoid)
A custom database is a UI problem as much as it is a data problem. The schema you pick is the UX you ship.
When a team asks for a "custom database," they almost never mean the raw data store. They mean the layer of tables, forms, filters, and permissions that lets the team do their real job.
Design the views first
Before you draw an ERD, list the five or six views the team actually opens every day: the pipeline, the queue, the weekly report, the on-call board. If a schema decision makes any of those views awkward, that is a signal to redesign—not to add another report.
Three shapes to avoid
The spreadsheet-in-a-trenchcoat. One giant table with 80 columns because "it is easier to query." It is, until you add the second user and the first workflow.
The microservice cosplay. Ten tables of join-through polymorphic relationships because someone read a blog post. If your whole team is six people, a few well-named tables beat the pattern every time.
The permissions afterthought. Row-level security retrofitted on month six. Decide who sees what before you decide the shape.
What good looks like
The database you ship should let a new teammate open the UI, find the thing they need in under a minute, and trust the numbers they see. Everything else is internal plumbing.