Multi-modal schema source

✓ functional

Layer local files over the live database so the model can include the changes you are actively shaping.

Keep the live database as the baseline, then bring your checked-in DDL along for the ride. SQLly's model is built from more than one source at once - one or more connected databases, plus a folder of local SQL files - and merged into a single picture of your schema.

How the two sources are merged

Collection runs in parallel: database sources through their connection pools, files through a bounded pool of reader threads. Each collected object becomes a fragment tagged with its provenance - either the profile it came from, or the file path, content hash, and byte span it was parsed from. Fragments are staged against a generation counter, joined at a barrier, and swapped in as one immutable snapshot, so you never see a half-built model.

When both sources define the same object, the rule is deliberate and simple:

The file wins; the database is kept as a shadow. Your local definition is what completion and validation use, and the server's version is retained alongside it rather than discarded - so the difference is recorded rather than lost. It is not a “newest timestamp wins” guess, because a file's mtime is a poor witness and a silent coin-flip is worse than a stated rule.

Drift is a first-class answer

Because the losing definition is kept, the model can tell you exactly which objects differ between your working tree and the live server. Every object with a shadow is drift, listed by name, which turns “is staging up to date?” into a question with an answer instead of a hunch.

It stays live

File changes, file deletions, and database changes each notify the engine, and only the affected sources re-collect. An object removed and re-added in the same generation - which is what saving an edited file looks like from the outside - is reported as a change, not as a delete followed by an add.

Work against checked-in DDL before it is deployed.
Get completion for a table that only exists in your branch so far.
The query can still fail against the live database until the schema catches up. That distinction stays explicit; the overlay is helpful, not make-believe.