AI Database Intelligence: Understanding a Database You Did Not Build

Every engineer has inherited a database nobody can explain. There are 200 tables. Four of them look like they hold customers. The person who designed it left in 2021. There is no documentation, and the only reliable way to learn anything is to query it carefully and infer.

This is one of the most expensive forms of organisational debt, because it slows down everything downstream. New engineers take months to become productive. Analysts write queries against the wrong table. Migration projects stall because nobody can say with confidence what depends on what.

AI database intelligence attacks that problem directly: map the structure, document it, and let people ask questions about the database in plain language.

Watch the demo

The demo shows a database being mapped, an entity relationship diagram generated automatically from the live schema, and questions answered about both the structure and the contents.

The difference from text-to-SQL

These two are often confused, and the distinction matters when deciding what you need.

Text-to-SQL answers questions about your data. How many customers churned last quarter.

AI database intelligence answers questions about your database. Which table holds the authoritative customer record, what links orders to shipments, what this column actually contains, and what would break if we changed this field.

The second is what you need when the problem is comprehension rather than analysis. In practice most teams need both, and the intelligence layer makes the query layer significantly more accurate, because a well-documented schema is exactly what text-to-SQL depends on.

How it works

1. Introspect the schema

The system reads the database’s own metadata: tables, columns, data types, primary and foreign keys, indexes, and constraints. This gives the declared structure, which is the skeleton.

2. Infer the real relationships

Declared foreign keys are often incomplete. Databases that have evolved over years carry relationships that exist in application logic but were never declared at the database level. The system infers likely relationships from naming patterns, value overlap between columns, and cardinality, then flags them as inferred rather than declared. That distinction is important and should never be hidden.

3. Profile the contents

Structure alone is not understanding. Profiling samples each column to determine what it actually contains: distinct value counts, null rates, formats, and ranges. This is how you discover that a status column has seven values when the documentation mentions three, or that a field is 80 percent null and therefore probably abandoned.

4. Generate documentation and a diagram

The output is a readable entity relationship diagram plus written descriptions of what each table appears to hold. Generated from the live database, so it reflects reality rather than an out-of-date wiki page.

5. Answer questions

With structure and profile indexed, the system answers questions in plain language, citing the tables and columns behind each answer.

What it is genuinely useful for

Onboarding engineers and analysts. The ramp from “I have access” to “I know where things are” collapses from weeks to hours.

Migration and modernisation. Before moving off a legacy system, you need to know what exists and what depends on it. Doing that discovery by hand is slow and error-prone.

Data governance. Finding where personal data actually lives is a prerequisite for most compliance work, and in a large undocumented estate it is genuinely hard.

Improving other AI systems. Text-to-SQL quality depends directly on schema documentation. Generating that documentation makes the query layer measurably better, which is why these two are often deployed together.

Impact analysis. Understanding what a schema change would break, before making it.

Where it gets things wrong

Inferred relationships can be spurious. Two columns sharing values does not prove a relationship. Good systems mark inferences as provisional. Treat them as leads for a human to confirm, not as facts.

Naming lies. A table with “new” in its name may be older than the one without. A flag column may have stopped being maintained years ago. The system reports what it observes, and observation includes historical mess.

Business meaning is not in the database. The system can tell you a column contains three distinct integers. It cannot tell you that 2 means “suspended pending review” unless that is documented somewhere it can read. Structure is discoverable, semantics often are not.

Profiling touches data. Sampling contents means reading real records, which may include sensitive data. Where that profiling runs and what it retains needs deciding before you point it at production.

Very large estates need scoping. Introspecting thousands of tables produces something as unreadable as the original problem. Scope to a domain and expand.

What deployment looks like

Two to five weeks, which is faster than most systems of this kind because the input is structured and already exists.

Week 1. Connect with read-only access, scope to a domain rather than the entire estate, and confirm what data can be profiled.

Week 2. Introspect, infer, profile, and generate the first documentation pass.

Week 3. Have someone who knows the domain review the output. This step converts a good guess into reliable documentation, and it is the highest-value hour anyone will spend on the project.

Weeks 4 to 5. Add the question-answering layer, wire in access controls, and roll out to the teams who need it.

The review step is what people skip and then regret. The system produces a strong first draft. A domain expert turns it into truth.

Related use cases

Pair this with AI SQL generator, which uses the documentation this produces to write more accurate queries. For unstructured content rather than databases, AI document intelligence solves the analogous problem.

Browse everything in our AI use cases library.

Frequently asked questions

Does it need write access?

No. Read-only is sufficient and is what should be used. Introspection and profiling are both read operations.

Will it expose sensitive data?

Profiling reads real values, so this needs settling in advance. Options include profiling against a masked copy, excluding sensitive columns, or restricting where profiling output is stored.

How large a database can it handle?

Technically large ones, but usefully it should be scoped by domain. Documentation covering 2,000 tables is as hard to navigate as the database itself.

Is the ER diagram accurate?

Declared relationships are accurate. Inferred relationships are informed guesses and should be labelled as such, then confirmed by someone who knows the system.

Does the documentation stay current?

It can be regenerated on a schedule, which is the main advantage over hand-written documentation that rots the moment someone ships a migration.

Can it work across multiple databases?

Yes, and cross-database relationships are often exactly what nobody has documented, which makes this one of the more valuable applications.

AINinza is the AI practice of Aeologic Technologies, backed by over a decade of enterprise engineering. If your team is slowed down by a database nobody fully understands, we are happy to talk through what mapping it would involve.