Why Your Database Needs an AI Layer
Most database tools haven't changed much in twenty years. You open a GUI, write SQL, stare at a result set, copy it into a spreadsheet, and build a chart manually. It works, but it's slow. And it keeps the data locked behind a skill barrier that most of your team can't get past.
We built Ryuk because we kept hitting the same wall. Someone on the team had a question about the data and the answer was always stuck waiting on an engineer to write a query. That delay, even when it's short, kills momentum.
The problem isn't SQL#
SQL is good. It's been around for decades because it works. The problem is everything else around it.
You need to know the schema. You need to know which tables join to which. You need to remember whether that column is called created_at or createdAt or date_created. You need to know that the status column uses 1 for active and 0 for inactive because someone made that choice in 2019 and nobody wrote it down.
An AI layer doesn't replace SQL. It sits on top of it. You say what you want in plain language, it writes the query, runs it, and gives you the result. If you're technical, you can look at the SQL. If you're not, you don't need to.
What "AI layer" actually means#
There's a lot of vague marketing around AI in databases right now. Most of it is a text box bolted onto a query editor. Here's what actually matters:
Schema awareness. The model needs to understand your database structure. Not just table names, but relationships, data types, constraints. Without this it's guessing.
Query execution. Generating SQL is half the job. The other half is running it safely. Read-only connections, query timeouts, and making sure the model can't accidentally run DELETE FROM users because it misread your prompt.
Conversational context. If you ask "what were our top products last month?" and then follow up with "break that down by region," the model needs to know what "that" means. Stateless Q&A doesn't work.
Visualization. A table of numbers is fine. A chart is usually better. The model should pick the right format and generate it on its own.
The read-only constraint#
This is non-negotiable. When you give an AI agent access to a database, the agent should never be able to modify data. Not through prompt injection, not through query planner edge cases, not through anything.
In Ryuk, every connection is wrapped in a read-only transaction at the session level. It doesn't matter what the model tries to run. INSERT, UPDATE, DROP TABLE, whatever. PostgreSQL rejects it before it touches your data. This isn't application-level filtering where we parse SQL and look for bad keywords. That approach has holes. Session-level read-only is enforced by the database engine itself.
Who this is for#
The obvious answer is non-technical people who need data. Product managers, ops teams, founders who want to check a metric without filing a ticket.
But it's also for engineers. Not because they can't write SQL, but because sometimes they just don't want to. You want to know how many users signed up this week. You could open a terminal, connect to the database, recall the schema, write a query. Or you could type a sentence and have the answer in two seconds.
Good tools work for both kinds of people without talking down to either.
Community databases#
We built community databases so anyone can see what this looks like in practice. Browse available datasets publicly, sign up with a free account, and start asking questions. No database setup, no credentials, no config on your end.
If you've wanted to explore a dataset but didn't feel like spinning up a local Postgres and loading a SQL dump, that's what this is for.
We're a small team building this as we go. If you have thoughts on how this should work, or if something is broken, we want to hear about it.