Bring the database you already have

Most tools in this category start you at an empty table. That's fine if you're starting from nothing, and useless if you have four years of production data with foreign keys you'd rather not explain to a migration wizard.

So the first thing SchemaStack does with an existing database is read it.

What gets read

Connect the database — paste the connection string your provider gave you and the fields fill themselves in — and introspection walks it:

• Tables and columns, with types mapped from what the engine actually reports, including vendor-specific ones. PostgreSQL enum types come across with their values; MySQL's TINYINT(1) is recognised as the boolean it's pretending to be.
• Primary keys, including composite ones. (A column that's merely part of a composite key isn't marked unique on its own — a distinction that was once a bug and is now a test.)
• Foreign keys, with their ON DELETE / ON UPDATE behaviour, plus the reverse side so a customer knows about their orders and not only the other way round.
• Indexes, unique and composite.
• Auto-generated columns — identity, serial, defaults, timestamps — marked as not-yours-to-fill, so the grid and the API stop asking you for them.

Then you have a workspace: a spreadsheet-style grid over your real tables, an instant REST API, and validation you can add on top. Your database is unchanged. Import issues no DDL — it reads.

And then it keeps up

Databases move. Someone runs a migration from your application repo, a colleague adds a column in psql. SchemaStack notices: a fast hash comparison answers "has anything changed?", and a full check reports what, table by table. Sync reconciles the metadata to match. That's a post of its own.

What it doesn't do (yet)

Worth knowing before you point it at something complicated:

• Junction tables import as ordinary tables. A pure link table with two foreign keys is a table, not an inferred many-to-many — you add the relationship column deliberately, which also lets you say which field to display.
• Database views import, but drift checking treats them as tables. They can't be edited (correctly — they're not writable), and the compatibility docs still describe views as unsupported, which understates it.
• Not imported at all: triggers, stored procedures and functions, materialized views, partitioned tables, PostGIS types, table inheritance, domain types, exclusion constraints, and CHECK constraints — the last because reading them needs information_schema access that not every connection has.
• Partially imported: composite unique constraints arrive as an index rather than a column-level unique; partial indexes lose their predicate; PostgreSQL array types land as text; expression indexes lose the expression; INTERVAL becomes text.
• Import runs asynchronously for large schemas and resumes if interrupted — but there's no progress bar worth the name yet.

None of that touches your data. The honest summary: SchemaStack understands tables, columns, keys and indexes well, and understands the exotic parts of Postgres not at all. If your schema is mostly the former, it'll feel like it already knew your database. If it leans on the latter, check the compatibility list first — it's written in fully / partially / not-yet terms, deliberately.