cloudparts

Database clients and design tools

The tools people use to look inside and change a database: SQL clients that browse and query it, diagram tools that draw its tables and keys, and migration tools that change its schema from files kept in version control.

6 technologies on this page ↓

How it works

All three families start by reading the database’s own catalog, the system tables (information_schema, pg_catalog, sys) that list every schema, table, column, index and foreign key. A SQL client connects through a driver: JDBC or ODBC for general-purpose desktop tools, a native wire protocol, or an HTTP API for the browser editors in cloud consoles. It turns the catalog into an object tree and into autocompletion in a SQL editor, runs the statements you type, and shows the rows in a grid. Editing a cell in that grid makes the client write the UPDATE for you; most clients also show execution plans and export results. A diagram tool reads the same tables, columns and foreign keys and draws an entity-relationship diagram: one box per table, one line per foreign key, with crow’s feet marking the “many” end. Some connect to the database, others ask you to run one query and paste its JSON output, so they never hold a password, and some start from text: you type the schema in a small language such as DBML and the diagram follows, and the tool can turn the text into CREATE TABLE statements. A migration tool changes the schema itself, in one of two ways. Versioned tools keep an ordered folder of migration files (20261023_add_discount.sql) and record in a table in the database which ones already ran, so every copy of the database applies the same steps in the same order. Declarative tools keep only the desired schema, as SQL, HCL or ORM models; they inspect the live database, compute the difference and plan the ALTER statements, much as Terraform does for servers. Either way, a linter can check each planned change before it runs, flagging dropped columns, table rewrites that lock a busy table, or a NOT NULL column added without a default.

Think of it as

A building’s three kinds of paperwork. The SQL client is the caretaker’s master key: you can walk into any room, look around and move the furniture. The diagram is the floor plan pinned in the lobby, showing which rooms connect to which. The migration files are the renovation permits: every change to the walls is written down, numbered and approved before the builders start, so the next building of the same design can be changed the same way.

Reach for it when

  • Exploring an unfamiliar database: browse the object tree, read the diagram, and try queries before writing application code
  • Debugging and support work that needs a quick look at real rows, a query plan or a lock, without writing a script
  • Any schema that more than one environment or developer shares: keep changes as migration files or a declarative schema in Git, reviewed and applied by CI, instead of typed by hand into production
  • Designing a new schema or explaining an existing one: a diagram written as text can be diffed, reviewed and kept next to the code

Think twice when

  • Changing the production schema by hand in a GUI client: the next environment won’t get the same change, and nothing records it. Write a migration instead
  • Treating a diagram as the source of truth when the database or the migrations already are: a drawing that isn’t generated from the schema goes stale
  • Pasting production data into an AI assistant inside a client: check what the tool sends. Most send only the schema and your prompt, but the setting is per tool
  • Reports that many people need every day: a BI or notebook tool, not a personal SQL client, is the place to share queries and charts

A real example

A shop adds a discount to orders. The developer adds a discount_cents integer NOT NULL column to schema.sql and runs atlas migrate diff add_discount, which compares the file with the migration folder and writes a new migration file with the ALTER TABLE. In the pull request, atlas migrate lint flags it: adding a non-nullable column without a default fails on a table that already has rows. The developer adds DEFAULT 0, the check passes, and CI applies the migration to staging and then production, where Atlas records the version as applied. Afterwards a support engineer opens the orders table in DbVisualizer to check the new column, and the team regenerates its dbdiagram.io diagram from the live database with db2dbml, so the floor plan shows the change too.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
The Aurora query editor in the RDS console runs SQL on Aurora MySQL and Aurora PostgreSQL clusters that have the Data API enabled, and stores your login in Secrets Manager. Redshift query editor v2 is a separate web SQL client for Redshift, with a schema tree, charts and shared queries. AWS has no relational diagram or migration tool of its own; Atlas, for one, can authenticate to RDS with IAM.
Google Cloud
Cloud SQL Studio in the Google Cloud console queries Cloud SQL for MySQL, PostgreSQL and SQL Server from the browser, with Gemini to help write SQL. Each query is cancelled after five minutes, and responses over 10 MB are truncated.
Azure
The query editor in the Azure portal runs T-SQL against Azure SQL Database, with a five-minute timeout. For more, Microsoft points to SQL Server Management Studio (SSMS 22, with GitHub Copilot in preview) and the MSSQL extension for VS Code, which replaced Azure Data Studio when its support ended on February 28, 2026.
Open source & others
DBeaver Community (Apache 2.0, any JDBC or ODBC database) and phpMyAdmin (MySQL in the browser) are open-source clients; DbVisualizer and DB Pilot are commercial ones. ChartDB (AGPL) and DBML with dbdiagram.io draw diagrams. Flyway, Liquibase and Atlas manage migrations, and ORMs such as Rails’ Active Record ship their own.

Three kinds of tool#

They read the same catalog and answer different questions. Many products now cover two of them, such as a client that also draws diagrams.

KindQuestion it answersChanges the database?Examples
SQL clientWhat is in the database, and what does this query return?Only what you run or editDbVisualizer, DB Pilot, DBeaver, SSMS, Cloud SQL Studio
Schema diagramHow do the tables connect?No; some export DDL to run yourselfChartDB, dbdiagram.io
Schema migrationHow does the schema get from today’s version to the next, everywhere?Yes, through reviewed, recorded stepsAtlas, Flyway, Liquibase, Rails migrations

Versioned or declarative migrations#

The two styles differ in what you keep in Git: the steps, or the destination.

VersionedDeclarative
You writeEach change as a numbered migration fileThe desired schema, as SQL, HCL or ORM models
The tool works outWhich files haven’t run yet, from a history table in the databaseThe ALTER statements that turn the live schema into the desired one
Good atExact control over every statement, and data changes between stepsReviewing the whole schema in one place, and catching drift
Watch out forHand-written files that miss an index or disagree with the codePlans that drop or rewrite things; review them and lint them
  • Atlas supports both: it can write the next versioned migration file by diffing the desired schema against the migration folder.

Often confused with

Relational databasesObject-relational mappingInfrastructure as codeData notebooks
Where it came from1976–2026

The drawings came first. In March 1976 Peter Chen published “The Entity-Relationship Model: Toward a Unified View of Data” in ACM Transactions on Database Systems, and the same year Gordon Everest described the crow’s foot that still marks the “many” end of a relationship. For decades such diagrams were drawn by hand or in modelling tools and kept apart from the database they described.

Clients followed the databases onto developers’ desks. In 1998 Tobias Ratschiller started phpMyAdmin, a web front-end to MySQL written in PHP, and Roger Bjärevall started DbVisualizer, a Java desktop client that reached any database with a JDBC driver; its version 1.0 came out in 1999. DBeaver later took the same JDBC approach on Eclipse. The clouds added browser editors to their consoles, such as the Aurora query editor, Redshift query editor v2, Cloud SQL Studio and the Azure portal query editor, and Microsoft retired its own cross-platform client, Azure Data Studio, in favour of an extension for VS Code: support ended on February 28, 2026.

Schema changes moved into code. Ruby on Rails made migrations an everyday tool: timestamped files, applied in order, with a schema_migrations table recording which had run. Flyway brought the same idea to any database; Redgate bought it in 2019, when its free edition had over 23 million downloads. Then schemas themselves became text. Holistics released dbdiagram.io in October 2018, where you type a schema and the diagram follows, and turned its syntax into the open DBML language. In 2021 Ariga, founded by the creator of Facebook’s Ent framework, open-sourced Atlas, which treats the schema as desired state and plans the migration, “Terraform for databases”; it reached 1.0 in December 2025. By 2026 most of these tools had an AI assistant that writes SQL or schema changes; DbVisualizer and DB Pilot, for two, send it the schema but not the rows.

Why it’s built this way

One client for every database, through generic drivers
Developers and DBAs work with several databases, and learning a separate tool for each is costly. JDBC and ODBC let one client reach almost any of them; the price is that a database the tool doesn’t know well gets only basic features, which DbVisualizer, for one, marks as “basic support”.
Diagrams written as text
Drawing tables with a mouse is slow, and a picture can’t be diffed or reviewed. Typing the schema in a small language makes the diagram fast to change, easy to keep in Git, and convertible to and from SQL.
Keep the desired schema and let the tool plan the change
Hand-written migration files drift from what the code expects and are tedious for large schemas. A declarative tool computes the difference instead, the way Terraform does for infrastructure, and a linter checks the plan for destructive or locking changes before it runs.
Send the AI the schema, not the data
An assistant needs table and column names to write SQL, but rows can hold personal or confidential data. DbVisualizer and DB Pilot send only the prompt and the structure, and ChartDB never needs a database password at all.

Timeline

  1. 1976

    Peter Chen publishes the entity-relationship model; Gordon Everest describes crow’s foot notation

  2. 1998

    phpMyAdmin is started as a web front-end to MySQL

  3. 1999

    DbVisualizer 1.0, a Java client for any JDBC database

  4. 2018

    Holistics releases dbdiagram.io, whose syntax becomes DBML (October 22)

  5. 2019

    Redgate buys Flyway for $10 million (July)

  6. 2021

    Ariga open-sources Atlas, schema as code for databases (November 25)

  7. 2025

    Microsoft announces the retirement of Azure Data Studio (February 6); Atlas 1.0 (December 23)

  8. 2026

    Azure Data Studio support ends (February 28); DbVisualizer 26.2 lets users pick Anthropic, Google or OpenAI models (June)

Sources16

Improve this page on GitHub