Quellery only reads from your database. It never writes on its own. The only writes that happen are ones you initiate yourself — either by running a generated migration script, or by executing SQL you've written in the Queries tab. Both are explicit actions you take.
No. Quellery runs entirely within your environment. No telemetry, no update checks, no licence-validation pings — no outbound connections of any kind.
Database passwords are encrypted with AES-256 in GCM mode (128-bit authentication tag, 96-bit random IV per value) before being written to Quellery's own database (SQLite or PostgreSQL). The encryption key is derived from the ENCRYPTION_KEY environment variable that you supply, and is never stored alongside the data.
You can also choose to supply a password via an environment variable instead of storing it at all. When you add or edit a database connection, set Password Type to Environment Variable and enter the variable name (e.g. MY_DB_PASSWORD). Quellery reads the value from the process environment when it opens a connection pool, so the password itself never touches Quellery's database. The variable name is stored (it isn't a secret), but the value lives only in your environment.
User account passwords (for logging into Quellery itself) are never stored in plain text or reversibly encrypted. They are hashed with bcrypt using a work factor of 12 (212 rounds) and a random per-password salt, via the jBCrypt library.
Yes. When creating or editing a database connection, set Password Type to Environment Variable and supply the name of an environment variable that holds the password. Quellery resolves the value from the environment at connection time — the password itself is never written to Quellery's own database. This is useful when secrets come from a secrets manager, Kubernetes, Docker Compose, or an .env file, and you'd rather not have another copy.
No. Quellery is proprietary and there are no current plans to open-source it.
There are some very good database tools available, and Quellery isn't trying to replace them. Its focus is on schema exploration, refinement and documentation rather than querying. Quellery does let you run SQL against the database, but the query interface is deliberately primitive — if you want a polished SQL editor, use your existing tool alongside Quellery.
Lance Walton has thirty-four years of software architecture, design and development experience, spanning financial markets and investment banking (bond and FX trading systems, credit risk, reference data, client clearing, client onboarding), media, national health and care-home management, government, internet technologies, and analytics. He has a talent for getting systems into production where organisations have previously struggled to do so.
Lance has used Java since 1995 and Scala since 2008, with a keen interest in functional programming. He is a co-founder of Underscore.
Earlier in his career he was a consultant in California working on an analytics engine, and from 1990 to 1994 he conducted academic research into neural networks at the University of Kent, where he earned a PhD.
Quellery came out of several experiences with legacy databases where there was a lot of uncertainty about what could be relied on: whether a column really needed to be nullable, what implicit relationships existed between tables, what the magic numbers in a "type" column actually meant, what the form of a supposed identifier was. The information was usually scattered across the application code, tribal knowledge, and assumptions — rarely in the schema itself. Quellery is an attempt to make that implicit knowledge explicit, validate it against the live data, and — when the team is ready — push it back down into the schema where it belongs.