Model Google Cloud Spanner Schemas in DbSchema

Cloud Spanner co-locates related rows through interleaved tables, and that hierarchy decides how your globally distributed data performs. DbSchema reads the information schema and puts the whole structure — parents, children, secondary indexes, foreign keys — on an ER diagram.

Audit interleaving as explicit diagram edges, not DDL
Build and run Spanner SQL visually
Diff schemas between development and production instances
Publish HTML docs for teams without database access

available for

ISO-27001 certified

Free Community Edition No signup required 15-day Architect trial included

Free Download

DbSchema showing a Google Cloud Spanner schema as an ER diagram with documentation

Trusted by teams at

Interleaving Decides Where Data Lives
Raw DDL Keeps That Invisible

Whether a child table is interleaved in its parent determines physical co-location in Spanner's distributed storage — a design choice with real performance weight. Yet the hierarchy exists only as clauses scattered through CREATE TABLE statements.

DbSchema renders parent-child relationships as diagram edges, so architects can check the intended hierarchy at a glance and share it with every engineering team that touches the data.

Reverse Engineer, Query & Compare
Cloud Spanner from One Desktop App

The distributed database, handled with local tools on Windows, macOS, or Linux.

Reverse engineer the Google Cloud Spanner information schema into a diagram

The Interleaved Hierarchy, as Diagram Edges

DbSchema reads the information schema and lays out tables, secondary indexes, foreign keys, and parent-child interleaving on a navigable canvas.

Build Google Cloud Spanner SQL queries visually

Spanner SQL by Point and Click

Pick columns, joins, and filters in the visual builder; DbSchema composes the SELECT and executes it against your instance — handy for exploring large distributed datasets.

Compare Google Cloud Spanner schemas between instances

Catch Drift Between Instances

Diff the schemas of development and production Spanner instances, review the proposed DDL changes, and keep every environment on the agreed design.

The Instance Runs in the Cloud
The Design Lives in Your Model

DbSchema keeps the schema in a design model file of its own. Model new tables and interleaving strategies first, and apply them to the running Spanner instance once the design is settled.

Sketch Schemas Offline

Work on the design without a connection — the instance is needed only at apply time.

Version the Design

The model is a file, so Git tracks who changed which table, and when.

Read generated Cloud Spanner DDL before running it

Read the DDL First

Every planned change appears as statements you inspect before execution.

Apply the same Cloud Spanner change across environments

Roll Out in Stages

Carry one reviewed change from staging to production instead of retyping it.

Cloud Spanner Connection Facts

Spanner addresses databases through a three-level hierarchy — project, instance, database — and the JDBC URL spells it out: jdbc:cloudspanner:/projects/project/instances/instance/databases/database. DbSchema assembles this URL from the three names you enter. There is no traditional database port: traffic goes through the Cloud Spanner gRPC API on port 443.

Authentication uses Application Default Credentials — point GOOGLE_APPLICATION_CREDENTIALS at a service account JSON key file, or run gcloud auth application-default login to reuse your user credentials. DbSchema loads the Cloud Spanner JDBC driver (google-cloud-spanner-jdbc) through its driver manager; details are on the Cloud Spanner JDBC driver page.