Schema cache

✓ functional

Keep the schema tree quick with a local cache that checks itself whenever you reconnect.

SQLly keeps a local cache of each connection's schema - databases, tables, columns, keys, and routines - stored per connection and database. That is why the Server Explorer and IntelliSense can respond right away: the tree hydrates from the cache instead of waiting for a fresh round of catalog queries.

Seed, then revalidate

  1. Seed. On connect - or on relaunch - the cached model is loaded from disk and applied immediately. The tree is populated and completion works before the first catalog query returns.
  2. Revalidate. A fresh pull runs in the background and replaces the seed when it lands. Connecting always revalidates; switching database uses the in-memory model if it is already there.
  3. Refresh on demand. Refresh in the explorer header's overflow menu re-reads the schema after a migration, or a change someone made elsewhere.
A slow pull can never clobber a newer switch. Each refresh is tagged with the connection and database it was started for, and a result that arrives after you have moved on is discarded. The alternative - a late answer quietly repainting the tree with the previous database's schema - is the kind of bug that makes people distrust a cache entirely.

Hydration fills only what is missing

The tree is loaded lazily as you expand it, and hydration fills in the levels you have not expanded yet - using exactly the same identities the lazy loader would have. The visible consequence is a good one: the sidebar filter finds objects and columns inside nodes you have never opened, because the cache already knows they are there.

Managing it

Settings › IntelliSense Cache lists every cached model with its server, database, and age. Clear one, clear them all - the “clear all” button arms before it fires - or reveal the folder in Finder or Explorer. Clearing is always safe: the next visit simply does a full refresh, and the connection you are actively using never goes blank.

Cache files are ordinary JSON in your SQLly folder, written atomically and version-gated, so an old or damaged file is replaced rather than trusted. Nothing about your schema leaves the machine - see Everything is a file.