Connecting a production database, safely

Giving any tool access to a production database is a real decision. Here is exactly what ByeSQL can and cannot do once it is connected. All of it enforced in code, not promised in a policy.

SAFE Mode · Enforced by default

Your data cannot be modified

SAFE mode blocks every write operation at the query validation layer, before any SQL reaches your database. A statement is only allowed through if it starts with SELECT or WITH, and it is rejected outright if any of nine write keywords appears anywhere in it.

Even if an AI-generated query somehow contained a write operation, it would be caught and blocked. You can safely connect your production database on day one.

✕ INSERT✕ UPDATE✕ DELETE✕ DROP✕ CREATE✕ ALTER✕ TRUNCATE✕ MERGE✕ REPLACE✓ SELECT✓ WITH
AES-256 · Key separation

Credentials encrypted at rest

Database passwords are encrypted with AES-256 before storage. The encryption key lives in a separate secrets store, isolated from the application database.

If our database were ever breached, your credentials would not be recoverable in plain text. An attacker would have ciphertext with no path to the key.

Three more things the validator enforces

Read-only is the headline, but it is not the only guardrail between a generated query and your database.

One statement, always

A query is rejected if it contains a semicolon followed by anything other than whitespace. Only a single statement can ever reach your database, which removes the stacked-query class of SQL injection outright: there is no second statement to smuggle anything into.

Read the guide on SQL injection →

A row limit you cannot forget

Before it executes, every query is rewritten to carry a limit: 200 rows by default,5,000 maximum. If a prompt asks for more, the limit is lowered rather than honoured. A careless "show me everything" cannot pull a million rows through your connection.

A 20-second ceiling

Queries are cut off after 20 seconds. A generated join that would have run for ten minutes against a large table gets killed, and ByeSQL suggests narrowing the filters instead.

What ByeSQL reads, and what it keeps

Read from your database
  • Table and view names
  • Column names and data types
  • Primary keys, foreign keys and unique indexes, so generated joins follow your real relationships
  • The rows returned by each query, passed straight through to your browser
Stored by ByeSQL
  • Your prompt and the SQL that was generated from it
  • Execution status, row count and duration
  • Your schema, cached so prompts can be answered accurately
  • Never the rows themselves, and never used to train a model

ByeSQL only ever sees what the database user you configure can see. The recommended setup is a dedicated read-only user scoped to the tables you want exposed, which gives you two layers of protection instead of one.

If your database should never be reachable at all

The web app connects from ByeSQL's servers, so your database has to be reachable from the internet. If that is a non-starter, the desktop app connects directly from your own machine instead: localhost, a private LAN or a VPN-only host all work, and neither the connection nor the results pass through our infrastructure.

Download the desktop app

Questions people ask before connecting

Can ByeSQL write to my database?

No. SAFE mode only lets a statement through if it begins with SELECT or WITH, and it rejects the query outright if any write keyword appears anywhere in it. This runs before the SQL is sent to your database, and it is not a setting you or we can switch off.

What stops a generated query from running several statements at once?

A query containing a semicolon followed by anything other than whitespace is blocked. Only a single statement can ever reach your database, which removes the stacked-query class of SQL injection entirely.

Can a huge query take my database down?

Every query is rewritten to carry a row limit before it executes: 200 rows by default, 5,000 maximum. Queries are also cut off after 20 seconds.

What happens to my credentials if ByeSQL is breached?

Database passwords are encrypted with AES-256 before storage and the key lives in a separate secrets store, not in the application database. An attacker holding a dump of our database would have ciphertext and no path to the key.

See all frequently asked questions →

Connect a read-only user and see for yourself

Free plan, no credit card. Point it at a staging database first if you prefer.

Get started free