If you reach a level of complexity where it makes sense you should use it.

If you reach a level of project maturity where you don't have (or want to have) the entire db model in your head you should use it.

If you have multiple models in different systems you should use it.

If you work with other people and you want to make it easier to communicate db models you should use it.

If you want to communicate db models publicly you should use it.

If you want to plan your db models in advance you should use it.

When I say you should use it I mean the end diagrams, I don't specifically mean this tool.

I've used tools like this to get my thoughts together around a design I have in my head. Personally I like DBML, since it gives me something I can pretty easily keep in source control and there are plugins for my editor.

https://dbml.dbdiagram.io/home/

I was just thinking of dbdiagram.io. It's a fantastic tool that I use for documenting all my schemas.

Because "a picture is worth a thousand words"

Have you ever inherited a project with 80 tables and no documentation at all, or at best a 50 page document with database schema dumps?

You can draw it all on one page as an ERD (entity relationship diagram) with the main tables and their relationships. And this diagram can be understood in minutes, not hours/days like in the case of the schema dumps.

Also you can use various ERD editors, or text-based diagramming tools, like PlatUML, MermaidJS, DBML, on the schema design stage, while keeping the diagram sources in the source control.

Another usecase is to generate a detailed ERD for the current database schema in CI, and periodically review it, to ensure it conforms to the original design, and you understanding of the current schema is correct.

For me it makes it significantly easier to communicate with business and explain things like technical limitations and data requirements. It also helps with collaborative design on complex projects, making it clear where we're failing to meet data requirements

It's like documentation (javadocs, other sorts of documentation) - it gives you more concise view of how/what thing does.

I loath mentality "but the code is self explanatory!" :/

Same reason you might write out other specifications or maybe make a flow diagram of states something might go through in your application.

Certainly, with complex relations between various tables, having a design tool like this can help you visualize what you are doing. This in turn can help you in spotting things you might otherwise overlook.

Some of it depends on the sort of database work you do and how complex your database will be. If you only have a few simple tables with virtually no relations between them, this might indeed be overkill for you.

I use tools like a persistence layer for my thoughts. I can "think in words" but my brain defaults to "thinking in pictures" mode. When I think about a database schema I automatically visualize the tables and the connections between columns in a way similar to how most of these tools visualize the schema. My usage of these tools is more or less of me replicating what I see in my mind as a "save state" that I can resume in a day, month, or year.

I developed tools related to this, and have some guesses why some people see value and some don't:

1. A lot of the diagram-based modeling/visualization languages and tools are too simple, or poorly rendered, missing most of the potential value. (For example, for some product segments I knew, sold via enterprise sales, most of the offerings seemed to be developed by people who didn't use it themselves, and didn't have guidance from a domain expert.)

2. A lot of the examples people see of them are too simple, and often just plain wrong. (I was lucky to have a colleague explaining a complicated system by talking people through a rich diagram, and it was borderline epiphany. Then later I saw product managers and engineers make diagrams that were obviously incorrect/nonsensical, and otherwise weren't useful.)

3. I have a suspicion it might also sometimes involve some people having different "visual" or "spatial" thinking than others. Given a rich diagram in a familiar standardized visual language, do some people reason about it more visually than others, who are, say, reading it more like verbally, and reasoning from concepts that way?

It makes is so much easier to discuss things with other devs if there is even a scratch-level diagram of flow/data/api etc. Especially if it allows making comments, we use Figma at my company and for personal projects I use draw.io

It’s also handy reference for constructing queries for a DB that I might not be familiar with.