Your question doesn't include the size or complexity of the database you're trying to visualize. With that preface said, schemaspy has been around for years and years and I've seen it at every tech company I've ever worked at for visualizing their production databases. I think it's free?
This might be silly, but having tools like that built into MySQL Workbench, alongside both forward and backward engineering (get SQL from model and apply it, or get a model from an existing DB) is one of the reasons why I very much enjoyed working with it: https://dev.mysql.com/doc/workbench/en/wb-eer-diagrams-secti... (I might otherwise often prefer PostgreSQL, especially due to the procedural language and transactional DDL), also works fine with MariaDB for the most part
In most projects I've seen people just do some generic models (not even proper ED diagrams) and write some SQL migrations to be applied with something like dbmate or Flyway and call it a day, though working on DB schemas feels like one of the areas where model driven development actually makes a lot of sense and feels natural, if the tooling is there! Otherwise you end up with the actual schema and the models you make diverging slightly over time, either due to people forgetting to add stuff, or you yourself missing something. That's also why I enjoy the likes of DbVisualizer for getting a nice overview about what's actually in the schema: https://www.dbvis.com/
Language in that gif reminds me of DOT, from apt install graphviz which is pretty widely used I think. Various tools I use (including some I wrote or worked on) output to DOT format because it's so simple, and from there you tell the tool to make it into the appropriate format for your pdf report or webpage or so: `cat diagram.dot | dot -T png > diagram.png`. The DOT format is not as simple as dbdiagram though! But it's also not limited to database diagrams: https://en.wikipedia.org/wiki/DOT_(graph_description_languag...
In case someone wished this exists but for something other, or more versatile, than database diagrams, although dbdiagram as a product looks way more polished and integrated
$ man dot | grep --context=10 svg
OUTPUT FORMATS
Graphviz uses an extensible plugin mechanism [...] Traditionally, Graphviz supports the following:
-Tdot (Dot format containing layout information),
-Txdot (Dot format containing complete layout information),
-Tps (PostScript),
-Tpdf (PDF),
-Tsvg -Tsvgz (Structured Vector Graphics),
-Tfig (XFIG graphics),
-Tpng (png bitmap graphics),
-Tgif (gif bitmap graphics),
-Tjpg -Tjpeg (jpeg bitmap graphics),
-Tjson (xdot information encoded in JSON),
-Timap (imagemap files for httpd servers for each node or edge that has a non‐null href attribute.),
-Tcmapx (client‐side imagemap for use in html and xhtml).
Doesn't seem to work on mobile at all. Tables that I add are not shown in the diagram. The diagram area is not visible unless I scroll sideways.I cannot scroll sideways, unless I request desktop site and scroll there. But I still don't see any entities in the diagram. When I use the buttons to add tables in the diagram, they also do not show up in the grid, but only on the left in the textual list of tables. Seems like a complete non-functional tool on mobile.
Usually I wouldn't care too much about a tool like this running on mobile, but not at a PC right now, so that's all I can give feedback about.
I use it in my project to document the schema. We keep the markdown file in source control so that we update it whenever we make database changes. We also have an extension that allows viewing it as the diagram in vscode in our .vscode\extensions.json file.
There are some disadvantages however:
1. The foreign key relationships aren't completely clear
2. The diagram became difficult to navigate in vscode as our schema grew in size
I think most people would mean something like using the foreign key constraints information schema views to understand the relationships, print out the columns, etc - its really a pretty trivial SQL query to create mermaid relations (though your engine of choice may not have all the metadata you want) but its actually difficult to find the right level of granularity - its very easy to make a lot of visual noise in mermaid.
I have an issue with calling any of the diagrams created by all the tools mentioned "ER Diagrams". Entities are not the same thing as tables, and Sr diagrams are not relational database table diagrams. A (semi) visual representation of a database schema of any size that'd require a visual representation is almost necessarily a mess, and doesn't really help discussion or design. It is at best a faster indexing into the DDL for the tables.
What I'd love to have (but never saw an affordable tool) is the ability to work at different levels of abstraction: physical (which is what all tools here actually do), logical (hiding field details, normalization and de normalization, giving better business entity names, etc) and conceptual (to show how big picture concepts relate, domain boundaries, department dependencies/relationships).
Just the physical representation does, for my purposes, little more than code highlighting.
Maybe it is me but I never find those relationships diagrams that useful.
When structure is obvious then it is obvious and I don’t need a diagram - when structure is convoluted diagram is such a mess anyway that it is not helping at all.
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!)
I'd default to CategoryID being a string, with uniqueness constraints defined on the categories table. And UnitPrice to be a composite type, containing a [u]int amount and a string denomination, e.g. `10000 USD_CENT` or something like that.
But what you or I or anyone thinks is the right type for these or any columns, is totally beside the point. The point is that the type for a column isn't really assume-able by an LLM, at least not automatically.
In case it's useful to anyone in here, I wrote a little app at erdraw.com which is specifically designed to be a way to draw a data model in the notation of "Mastering Data Modeling" by Professor John Carlis. It serves somewhat different goals than these other tools. It prioritizes user understandability to be useful in conversations non-engineers. So it excludes technical details like data types and SQL.
Looks cool, but a bit of a bummer it's not open source. These days when I need to sketch out SQL/database diagrams, I usually have an LLM generate Mermaid code for me — good enough for quick drafts.
If I want something cleaner or a little more "presentation ready," I switch to d2 (https://d2lang.com/tour/sql-tables/#basics). It's got really simple syntax and does a great job laying out entity-relationship diagrams without much tweaking.
Tooling is a big reason I would reach for SQL Server over alternatives in many scenarios. Combining SSMS with 1-2 RedGate utilities and an Excel license is essentially the one ring of database management.
When you have a complex data model and need to constantly engage the business regarding it, having an easy way to transform, compare and visualize representations of the schema can mean the difference between ~3 clicks and a multi-day journey into the rabbit hole of shiny technology.
I would still reach for SQLite in any scenario where I am embedding the DB in software that I am distributing. But, if I need to stand up a database that multiple systems and users are all going to talk to, I am always going to advocate for spending a little bit of money.
> Combining SSMS with 1-2 RedGate utilities and an Excel license [...] a complex data model and need to constantly engage the business regarding it
SSMS suffers greatly from not having a Jupyter Notebook-style mode; whereas SSMS' cousin in Azure Data Studio does feature it, it's still thoroughly compromised in other ways to make it useless, unfortunately.
It's really convenient for being able to quickly whip up diagrams to share for discussion. Like when you have a small group of folks that need to iterate on a DB design, it's super simple to change things.
I've used this a bunch early in projects where the team needs to agree on DB structure:
1. whip something up as a discussion piece
2. usually a quick meeting to iterate on it, spot problems, correct.
3. you're close enough to build the DB bits, ship it. :)
Just for fun you can explain the domain problem to an LLM, then ask it for the dbdiagram json representation. Fix any issue you may spot, then ask the LLM to convert it to Jhipster modeling language (JDL) and import it with the cli. For me that’s the type of workflow that involves AI, rather cursor/windsurf/claude approach.
Is there a way to switch to numerical multiplicities/cardinalities? I always find the circle and feet notation not very readable and also less precise in some cases.
My personal go-to tool for this kind of diagram may remain yEd graph editor for now.
I was also very interested in finding a TF auto-diagramming tool at some point. After researching some examples however, I became convinced that it's not something I actually wanted or could make proper use of.
The issue I had with them is that they were just plain confusing and "noisy". After reflecting on it a bit, this made sense. Diagrams are only ever easy to follow if they have a clear purpose, but with minimal to no human semantic context, these auto generated diagrams could never be that way. They were just aimless scattershots of boxes with pretty icons on them.
Maybe it was just me not being used to them enough, and I could have grown to appreciate them and utilize them well if I bothered for long enough. But if I think about what I'd want from a diagram, it would be things like how data flows through an infrastructure, which Terraform cannot hope to have an exact idea about. And this only gets worse when you upload custom code, such as by using lambdas, containers, ec2 instances, what have you.
The Apache-licensed DBeaver is too limited for my needs: it exists to advertise their "DBeaver PRO" commercial license and features, but even then you cannot get a perpetual license for DBeaver PRO: it's subscription-only; their Enterprise edition claims to not require Internet access - but is not intended as a single-user software product (and it's priced accordingly).
In short: DBeaver simply won't sell me what I actually want.
Honestly, i love dbeaver but the fact it doesn't respect GTK nicely and the UI hasn't gotten much love makes me want to switch to something else. I know most people don't really get bothered by it, so I'd say it's not that big of a deal. It is for me though
What else is on the table that is similarly nice? The only other contender of which I am aware is DataGrip.
I likely only use 1% of the DBeaver features, so I do not necessarily need something as powerful, yet most of the database IDEs feel pretty anemic in their offerings.
insane the number of ways people handle diagrams - honestly i just get lost in all the tool options. you think having too many choices slows progress or actually helps in the long run?
I maintain an almost exhaustive list of text to diagram tools [1]. dbdiagram.io requires login to export.
Other dedicated text to database diagram tools are
1. Database Diagram Tool https://databasediagram.com/app
2. QuickDBD https://app.quickdatabasediagrams.com/#/
3. ERD Lab https://app.erdlab.io/designer/guest (Requires Login to Export)
[1]: https://xosh.org/text-to-diagram/
A bit more specialized, but still a nice list: https://wiki.postgresql.org/wiki/Design_Tools
Isn't editable diagram to text more useful?
I used to query databases and create diagrams from the metadata, but text to diagram just makes little sense to me.
You probably know this already but I’ll leave it for posterity.
https://mermaid.js.org/syntax/entityRelationshipDiagram.html
Is there a tool that can connect to a db and generate its own diagram?
Your question doesn't include the size or complexity of the database you're trying to visualize. With that preface said, schemaspy has been around for years and years and I've seen it at every tech company I've ever worked at for visualizing their production databases. I think it's free?
https://schemaspy.org/samples/chinook/relationships.html
Jet brains DataGrip is great for this. Compared to pgadmin an dbeaver. The DataGrip visualization options are so good that I grabbed a subscription.
100%… any new project I get involved I use DataGrip to build visualization to quickly get across the data model
Visual DB can do that: https://visualdb.com/
chartsdb[1][2] can be installed locally (or run through Docker) and import your database schema
[1]: https://chartdb.io/ [2]: https://github.com/chartdb/chartdb
DBeaver will generate an ER diagram from a connected DB
I find the auto-generated layout to be pretty poor. Requires a lot of jostling to get something more compact and immediately usable.
Proprietary and a bit pricy but Luna Modeller is good.
Thank you very much, interesting!
[dead]
This might be silly, but having tools like that built into MySQL Workbench, alongside both forward and backward engineering (get SQL from model and apply it, or get a model from an existing DB) is one of the reasons why I very much enjoyed working with it: https://dev.mysql.com/doc/workbench/en/wb-eer-diagrams-secti... (I might otherwise often prefer PostgreSQL, especially due to the procedural language and transactional DDL), also works fine with MariaDB for the most part
In most projects I've seen people just do some generic models (not even proper ED diagrams) and write some SQL migrations to be applied with something like dbmate or Flyway and call it a day, though working on DB schemas feels like one of the areas where model driven development actually makes a lot of sense and feels natural, if the tooling is there! Otherwise you end up with the actual schema and the models you make diverging slightly over time, either due to people forgetting to add stuff, or you yourself missing something. That's also why I enjoy the likes of DbVisualizer for getting a nice overview about what's actually in the schema: https://www.dbvis.com/
I usually go with the FOSS https://pgmodeler.io
Its feature-rich, albeit focused on Postgres. And it's ability to compare database schemas makes updating and applying diffs much easier.
Language in that gif reminds me of DOT, from apt install graphviz which is pretty widely used I think. Various tools I use (including some I wrote or worked on) output to DOT format because it's so simple, and from there you tell the tool to make it into the appropriate format for your pdf report or webpage or so: `cat diagram.dot | dot -T png > diagram.png`. The DOT format is not as simple as dbdiagram though! But it's also not limited to database diagrams: https://en.wikipedia.org/wiki/DOT_(graph_description_languag...
In case someone wished this exists but for something other, or more versatile, than database diagrams, although dbdiagram as a product looks way more polished and integrated
I think you can also convert it to SVG with the same tool.
Yep!
The FLOSS tool https://drawdb.vercel.app/editor has been here on HN several times. IMHO also does a somewhat better job.
Doesn't seem to work on mobile at all. Tables that I add are not shown in the diagram. The diagram area is not visible unless I scroll sideways.I cannot scroll sideways, unless I request desktop site and scroll there. But I still don't see any entities in the diagram. When I use the buttons to add tables in the diagram, they also do not show up in the grid, but only on the left in the textual list of tables. Seems like a complete non-functional tool on mobile.
Usually I wouldn't care too much about a tool like this running on mobile, but not at a PC right now, so that's all I can give feedback about.
I wouldn't think mobile is a primary workspace for doing any sort of diagramming, let alone ERD where its assumed the user has a PC.
It works on mine.
Mermaid is also great
https://docs.mermaidchart.com/blog/posts/7-er-diagram-exampl...
I use it in my project to document the schema. We keep the markdown file in source control so that we update it whenever we make database changes. We also have an extension that allows viewing it as the diagram in vscode in our .vscode\extensions.json file.
There are some disadvantages however:
1. The foreign key relationships aren't completely clear
2. The diagram became difficult to navigate in vscode as our schema grew in size
I found out about mermaid recently and have been using it to make diagrams. How do you use it for data modeling though?
Did you follow the link that the parent poster posted? It's exactly about how to do data modeling with Mermaid.
I think most people would mean something like using the foreign key constraints information schema views to understand the relationships, print out the columns, etc - its really a pretty trivial SQL query to create mermaid relations (though your engine of choice may not have all the metadata you want) but its actually difficult to find the right level of granularity - its very easy to make a lot of visual noise in mermaid.
What do you mean by data modelling? Which UML part? You start the diagram with a `erDiagram`
While discussing data models, my colleague was sketching tables and their relationships in an editor: table A, table B, columns linking them.
He then generated SQL from the diagram and deployed the schema to PostgreSQL. The schema was shared and reviewed.
The tool is https://dbdiagram.io
You can import/export SQL and generate images of your schema.
DBML is great. I hope it becomes a standard
I made a database ORM editor too: https://tinspin.itch.io/node
Mine is a desktop Java app. that exports XML that then gets converted to SQL (create.sql)
and ORM Java sources with the matching SQL queries. No reflection, just code generation.
Should work with MySQL (MariaDB), Postgres and Oracle.
You're cool!
I have an issue with calling any of the diagrams created by all the tools mentioned "ER Diagrams". Entities are not the same thing as tables, and Sr diagrams are not relational database table diagrams. A (semi) visual representation of a database schema of any size that'd require a visual representation is almost necessarily a mess, and doesn't really help discussion or design. It is at best a faster indexing into the DDL for the tables.
What I'd love to have (but never saw an affordable tool) is the ability to work at different levels of abstraction: physical (which is what all tools here actually do), logical (hiding field details, normalization and de normalization, giving better business entity names, etc) and conceptual (to show how big picture concepts relate, domain boundaries, department dependencies/relationships).
Just the physical representation does, for my purposes, little more than code highlighting.
Maybe it is me but I never find those relationships diagrams that useful.
When structure is obvious then it is obvious and I don’t need a diagram - when structure is convoluted diagram is such a mess anyway that it is not helping at all.
I have found that ChatGTP and Claude are good at converting a picture of a schema to SQL. So I sketch the schema by hand and the LLM creates the SQL.
It can also save the picture as a mermaid text for future edits. Pretty neat.
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.
"A picture of a schema"? What does this mean?
And by SQL do you mean DDL?
> "A picture of a schema"? What does this mean?
A hand-drawn picture of a database schema. Something like this:
https://www.dreamstime.com/stock-images-database-schema-imag...
> And by SQL do you mean DDL?
DDL is a subset of SQL, so the distinction is moot.
Huh, weird stuff!
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?
LLMs can infer a lot of details from "common sense" (i.e. statistical association). As a human, I can figure out what each field's types should be, so your frontier LLM could, too: https://chatgpt.com/share/680e3a90-8660-8003-998f-91ad98e32f...
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!)
I'd default to CategoryID being a string, with uniqueness constraints defined on the categories table. And UnitPrice to be a composite type, containing a [u]int amount and a string denomination, e.g. `10000 USD_CENT` or something like that.
But what you or I or anyone thinks is the right type for these or any columns, is totally beside the point. The point is that the type for a column isn't really assume-able by an LLM, at least not automatically.
That is a very nice tool! I might use it.
In case it's useful to anyone in here, I wrote a little app at erdraw.com which is specifically designed to be a way to draw a data model in the notation of "Mastering Data Modeling" by Professor John Carlis. It serves somewhat different goals than these other tools. It prioritizes user understandability to be useful in conversations non-engineers. So it excludes technical details like data types and SQL.
https://erdraw.com
Looks cool, but a bit of a bummer it's not open source. These days when I need to sketch out SQL/database diagrams, I usually have an LLM generate Mermaid code for me — good enough for quick drafts.
If I want something cleaner or a little more "presentation ready," I switch to d2 (https://d2lang.com/tour/sql-tables/#basics). It's got really simple syntax and does a great job laying out entity-relationship diagrams without much tweaking.
Tooling is a big reason I would reach for SQL Server over alternatives in many scenarios. Combining SSMS with 1-2 RedGate utilities and an Excel license is essentially the one ring of database management.
When you have a complex data model and need to constantly engage the business regarding it, having an easy way to transform, compare and visualize representations of the schema can mean the difference between ~3 clicks and a multi-day journey into the rabbit hole of shiny technology.
I would still reach for SQLite in any scenario where I am embedding the DB in software that I am distributing. But, if I need to stand up a database that multiple systems and users are all going to talk to, I am always going to advocate for spending a little bit of money.
> Combining SSMS with 1-2 RedGate utilities and an Excel license [...] a complex data model and need to constantly engage the business regarding it
SSMS suffers greatly from not having a Jupyter Notebook-style mode; whereas SSMS' cousin in Azure Data Studio does feature it, it's still thoroughly compromised in other ways to make it useless, unfortunately.
If you need it for your warehouse (Snowflake/Databricks) - take a look at SqlDBM: https://sqldbm.com/
It's really convenient for being able to quickly whip up diagrams to share for discussion. Like when you have a small group of folks that need to iterate on a DB design, it's super simple to change things.
I've used this a bunch early in projects where the team needs to agree on DB structure:
1. whip something up as a discussion piece 2. usually a quick meeting to iterate on it, spot problems, correct. 3. you're close enough to build the DB bits, ship it. :)
I’ve been using Mermerd [1] for years and never looked back. Simple, does one thing well.
It gets even better with elk layout - just prepend this frontmatter snippet to mermerd’s output:
[1]: https://github.com/KarnerTh/mermerdJust for fun you can explain the domain problem to an LLM, then ask it for the dbdiagram json representation. Fix any issue you may spot, then ask the LLM to convert it to Jhipster modeling language (JDL) and import it with the cli. For me that’s the type of workflow that involves AI, rather cursor/windsurf/claude approach.
Is there a way to switch to numerical multiplicities/cardinalities? I always find the circle and feet notation not very readable and also less precise in some cases.
My personal go-to tool for this kind of diagram may remain yEd graph editor for now.
I would absolutely love a free tool that compiled SQL into UML suitable for diagrams and visual exploration.
BTW, one that did the same for Terraform would make my life so much easier…
I was also very interested in finding a TF auto-diagramming tool at some point. After researching some examples however, I became convinced that it's not something I actually wanted or could make proper use of.
The issue I had with them is that they were just plain confusing and "noisy". After reflecting on it a bit, this made sense. Diagrams are only ever easy to follow if they have a clear purpose, but with minimal to no human semantic context, these auto generated diagrams could never be that way. They were just aimless scattershots of boxes with pretty icons on them.
Maybe it was just me not being used to them enough, and I could have grown to appreciate them and utilize them well if I bothered for long enough. But if I think about what I'd want from a diagram, it would be things like how data flows through an infrastructure, which Terraform cannot hope to have an exact idea about. And this only gets worse when you upload custom code, such as by using lambdas, containers, ec2 instances, what have you.
I am using Visual Studio Code with a dbml extension. I enjoyed learning dbml with dbdiagram.io.
What's wrong with dbeaver?
> What's wrong with dbeaver?
The Apache-licensed DBeaver is too limited for my needs: it exists to advertise their "DBeaver PRO" commercial license and features, but even then you cannot get a perpetual license for DBeaver PRO: it's subscription-only; their Enterprise edition claims to not require Internet access - but is not intended as a single-user software product (and it's priced accordingly).
In short: DBeaver simply won't sell me what I actually want.
Honestly, i love dbeaver but the fact it doesn't respect GTK nicely and the UI hasn't gotten much love makes me want to switch to something else. I know most people don't really get bothered by it, so I'd say it's not that big of a deal. It is for me though
What else is on the table that is similarly nice? The only other contender of which I am aware is DataGrip.
I likely only use 1% of the DBeaver features, so I do not necessarily need something as powerful, yet most of the database IDEs feel pretty anemic in their offerings.
can it export to other graph drawing languages like graphviz or mermaid?
It seems like there was no such possibility.
insane the number of ways people handle diagrams - honestly i just get lost in all the tool options. you think having too many choices slows progress or actually helps in the long run?
I can recommend drawsql
have a look at plantuml
I’ve used it in the past really like it.
This has been there forever.
Another Web-only tool. Bummer.
[flagged]