I had the opposite problem, was given SQL ddl with near 1000 tables and hundreds of constraints, and had to produce the schema map. Ran the ddl and connected it to yEd, and hey presto, schema map!
The truth is that if you are modeling a relationship set of 1000 tables you probably cant usefully show that to someone - you can produce an image but nobody can likely use it.
Instead, consider breaking things down to functional areas and then modeling those - just like how most city thinking is "well get on this main road and then this secondary road will get me to XYZ"
That's a good point, but to extend my situation, it's a client database I've been asked to transform. The map is indeed difficult to grok all in one, but using different views that come out of the box in yEd, along with some basic rules such as "make all nodes with the word 'cust' yellow", it's been surprisingly effective at exploring the schema.
Your linked image shows what appear to be tables, and the little arrows appear to represent entity-relationships between them. But I'm not sure how you'd get useful DDL out of it -- none of the columns have types, no indices, etc.!
Maybe an LLM could sketch out a DDL skeleton from a picture, which someone could use as a starting point?
You and a LLM can guess at what the types might be, but those guesses are a suggestion that a human needs to evaluate, they're not something you can just pass thru as assumptive defaults. In your link, for example, I would definitely not want CategoryID to be an INT, or UnitPrice to be a DECIMAL, or etc.
Sure, yeah - but just like with a human, I can provide additional domain context that can clarify its answer. I see your point - you need to know what to provide in order to get the result you want - but I think that today, that makes it a very useful tool, and tomorrow, it'll be able to make those clarifications itself.
(Out of curiosity, what would you use instead? I'd default to INT/DECIMAL respectively myself - would love to know what your thinking is here!)