DB CONSOLE

🔌 Two kinds of database — point it at yours

• SQLite — a database that is a file. Open one directly, or let the console find them for you: you approve the folders it may look in, it checks every candidate file's identity header to be sure it really is a SQLite database, and lists each one it finds — with its size and table count — once, even if it turns up in two places. It looks only in folders you approved; the program arrives knowing no folders at all.
• PostgreSQL — a database that is a server. Fill in a short form: the server's address, its port, the database name, your username. The address field ships empty — the first address it ever holds is one you typed — and the connection it makes is a real one, to the server you named.

Connections you keep are saved by name, in your own words. A saved connection remembers the directions — address, port, username, file paths — never the password: the saving code itself strips anything shaped like a password before the list touches the disk. Passwords live in one place only: the vault, below.

👀 Looking around — tree, grid, structure

• The schema tree — the database as an outline: its tables and views, each opening to show its columns. The map, before you touch anything.
• The data grid — one table's rows, 50 to a page. Click a column heading to sort by it; a search box hunts your words across every column at once. Empty cells show as NULL, binary data as a plain label like [blob 12B] — shown as what it is, never guessed at.
• The structure view — one table taken apart: every column with its type and default, the primary key, the foreign keys that link it to other tables in both directions, its indexes, and the table's real CREATE statement, readable and copyable.

Looking changes nothing. You can browse all day and the database will never know you were there — that is what read-only means, and it is the state you start in.

⌨️ The SQL editor

Write SQL — the database's own language — and run the whole thing or just the part you've selected. Answers land in a results grid, and results export to a CSV or JSON file on your own disk. A question can match a million rows; the grid shows the first 500 and says so — a capped answer is labeled capped, never quietly trimmed into looking whole.

Reading statements just run. Changing statements don't — an INSERT, UPDATE, DELETE, or DROP does not execute when you press run. It goes to the pending-changes tray, and the safety system takes it from there. That detour is not a refusal; it is the product working as designed.

🛡️ The safety system — the headline

• READ-ONLY BY DEFAULT — THE GOLD FRAME. Every connection starts read-only, and the window frame carries the mode in color at all times: gold means read-only — look at everything, change nothing; red-edged means writable — a connection you personally flipped, per connection, remembered. You can see your danger level from across the room.
• THE PENDING-CHANGES TRAY. Changes collect in a tray that shows you, in plain SQL exactly as it will run, every statement about to execute — with a live counter in the frame. Commit runs the tray; Discard throws it away and the database never hears about it. Close the window with changes pending and the console asks you, by name, what to do with them.
• BACKUP BEFORE WRITE. When you press Commit, the first act is not the change — it is the copy. A SQLite database is copied whole to a timestamped .bak file before anything executes, so the backup exists even if a write then fails halfway; the newest ten are kept. A bad write is always undoable: put the backup back, and you are standing where you stood.
• THE GUARDS. A DELETE or UPDATE without a WHERE gets a plain-words stop before it can commit: this will change every row in the table. A DROP or TRUNCATE stays disarmed until you type the table's exact name to arm the Commit — no checkbox a stray click can tick — and that guard lives in the console's core, not just its buttons, so an unarmed DROP cannot commit by any road.

🔐 The vault — where passwords live

Passwords are never plain text, anywhere — not in the saved list, not in a log, not on a screen after you've typed them. They live in an encrypted vault: one file on your own computer, sealed with a master password you choose. The master password itself is never stored — forget it and the vault stays sealed; that is not a flaw in the design, that is the design. In plain words, the sealing runs your password through a one-way mill 600,000 times to make the key, then seals the secrets with AES-GCM, the standard authenticated encryption — change one bit of the sealed file and it will not open, rather than open wrong. The vault file is locked to your account alone (permissions 0600), a wrong password fails loudly, and a built-in fallback seals the vault on systems missing the standard encryption library — there is no road in this program that ends with a password sitting readable on a disk.

⚖️ The honest limits

• Two engines today. This build speaks SQLite and PostgreSQL. MySQL and MariaDB are on the plan for a later phase — they are not in this build, and this page won't pretend they are.
• Changes are written, not clicked. In this phase you change data by writing SQL in the editor; a point-and-click row-editing form is later-phase work. The safety system was built first, on purpose.
• The backup copy is a file's story. The timestamped .bak protects SQLite databases, which are files. For a PostgreSQL server, the net is the read-only default, the review tray, and the guards — stated plainly, because pretending a file copy exists for a server would be a lie with a progress bar.
• Two small cosmetics, owned. On a narrow window (800 pixels wide) the grid's page buttons can clip at the right edge; on a short window (600 pixels high) the schema tree gets squeezed. Both are known, both are cosmetic, and neither touches a single byte of your data.
• Proven on test databases. Every protection above was proven against purpose-built test databases — 37 core checks and 15 window checks, all passing. The program has never been pointed at a real working database in testing, on purpose. It is released only after the founder has used it with his own hands.

🔒 Your machine, your business

No accounts, no telemetry, no update checks — the console never reports back to anyone. Its only network traffic is connections you define, to your own database servers, when you connect to them. Before this build was allowed out, its insides were scanned string by string: it contains no built-in addresses at all — not ours, not anyone's. Everything it keeps — saved connections, the vault, your exports — lives in plain local files on your own machine, exportable and deletable, yours.

⬇️ Downloads

🐧 The program — Linux

📖 The manual (PDF)

The full picture of what DB Console does and how to drive it — ready to read before the program itself lands.

DB Console — How It Works (PDF)
The program manual — connecting to your SQLite and PostgreSQL databases, the tree, grid, and structure views, the SQL editor, read-only by default, the pending-changes tray, backup before write, the guards, the vault, and the honest limits. 8 pages · SHA-256: c8dfb6cf83f87e4fd6beb65d3bc5fc04508fd10c80a8bd4be57ead0b061c08e6