Schema cache
✓ functionalKeep 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
- 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.
- 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.
- Refresh on demand. Refresh in the explorer header's overflow menu re-reads the schema after a migration, or a change someone made elsewhere.
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.