Software companies
Can you license database schemas and SQL query histories?
By SourceX Editorial · Updated
Short answer
Database schemas and SQL query histories can be licensed when they are your company's own work and stripped of literal values and customer identifiers. Developers of text-to-SQL and data agents value schemas with documentation, plus queries tied to the business question behind them. Result rows almost never belong in the package.
Key takeaways
- A documented schema plus real queries against it is worth more than either one alone.
- Literal values in WHERE clauses are where customer names, emails and account numbers hide.
- Query results are customer or business data and normally stay out of the package.
- Consistent placeholders keep joins and filters meaningful after identifiers are removed.
- Customer-created fields and tenant schemas in a multi-tenant product need their own rights review.
Why would an AI developer want schemas and queries?#
AI developers want database schemas and SQL query histories because they show how people actually ask questions of business data. Text-to-SQL models and data agents have to cope with real schemas, with legacy tables, ambiguous column names and joins that only make sense once you know the business, not just clean textbook examples.
The most useful records connect three things: the question someone asked, the query that answered it and the schema it ran against. An analyst request in Jira or Slack, the dbt model or saved query that resolved it, and the review that corrected a wrong join together show reasoning a schema dump cannot.
| Asset | What it shows | What raises its value |
|---|---|---|
| Schema definitions | Tables, columns, types, keys and constraints | Column comments and data dictionary entries |
| dbt models and tests | How raw tables become business metrics | Descriptions, tests and documented lineage |
| Saved BI questions | Questions the business asks again and again | Titles and descriptions written in plain language |
| Ad hoc query history | How analysts explore and correct themselves | Links to the request that prompted the work |
| Migration files | How the schema changed over time | Commit messages and linked issues explaining why |
| Query reviews | Mistakes caught and fixed by a second person | Comments that explain the correction |
What has to be stripped from SQL before it leaves?#
SQL has to be stripped of literal values before it leaves, because filters are where real data hides inside otherwise harmless query text. A query that reads like a business question often carries a customer's name, an email address, an account number or an internal ID in its WHERE clause.
Replace identifiers with consistent placeholders rather than deleting them. If every occurrence of the same account ID becomes the same token, joins and repeated filters still make sense. Deterministic encryption is one way to do it: Google's Sensitive Data Protection API, for example, offers it alongside format-preserving encryption and recommends the deterministic option where the original character set does not need to be preserved.
- String and numeric literals in filters, IN lists and CASE expressions.
- Comments that name people, customers or deals.
- Table and schema names that include customer names, common in tenant-per-schema designs.
- Connection strings, credentials and service account names in scripts and notebooks.
- Dates or thresholds that reveal confidential business events, where your team judges them sensitive.
- Query results pasted into comments, notebooks or tickets.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Where do schemas and query histories live?#
Schemas and query histories live in more places than most teams expect, and each source carries its own retention limits and cleanup problems.
Warehouse query histories are often the richest source and the shortest-lived. Check your warehouse's documentation for how long it keeps history on your plan, and export it to your own storage if you want to keep the option of licensing it later.
| Source | What it holds | Watch for |
|---|---|---|
| Application repository | ORM models, migration files and seed data | Seed files built from production data |
| Data warehouse | Query history with user, time and query text | Retention windows that vary by product and plan |
| dbt project | Models, tests, documentation and lineage | Hardcoded customer filters inside models |
| BI tools | Saved questions, dashboards and schedules | Embedded result snapshots and shared links |
| Notebooks | Exploratory SQL together with its output | Result rows saved inside the file |
| Database logs | Slow query and audit logs | Bind parameters captured alongside the query |
How to clean query histories at scale#
Cleaning query histories at scale works best with a SQL parser rather than regular expressions, because a parser knows the difference between a column name and a string literal. Pattern matching misses literals inside nested subqueries and mangles quoted identifiers, and those errors are hard to spot in a large export.
Machine-generated queries deserve a decision of their own. Dashboards and schedulers produce large volumes of repetitive SQL that adds little beyond the first example, while hand-written analyst queries, with their false starts and corrections, show the reasoning that text-to-SQL builders look for.
- Parse each query with a parser that supports your warehouse's SQL dialect.
- Replace every literal with a typed placeholder, such as a string, number or date marker.
- Map identifiers that must stay joinable to consistent tokens, using a key held only by your team.
- Drop queries that fail to parse instead of passing them through untouched.
- Collapse near-duplicate queries from dashboards and schedulers, keeping one example of each.
- Scan the cleaned output for secrets and personal details, then review a sample by hand.
Whose schema is it?#
Your product's core schema is usually company work: your engineers designed it, and it lives in your repositories. The picture changes in multi-tenant products where customers create their own custom fields, objects or tables, because those definitions can reveal how a specific customer runs its business.
Internal analytics warehouses raise a separate question. The queries your analysts wrote are company work, but the tables they query may hold customer and user data. Licensing the query text and the schema, without the rows, keeps the package on the company-work side of that line. Have counsel confirm how customer agreements treat custom fields and derived schemas before including them.
Acquired products add one more layer. A schema inherited through an acquisition is only as licensable as the purchase agreement and the original developers' assignments make it, so confirm both before treating it as your own work.
Illustrative: a billing platform packages its analytics history#
Illustrative: a fictional subscription billing platform keeps its product schema in Postgres migrations, runs analytics in a cloud warehouse with a dbt project, and uses Metabase for saved questions. Analyst requests arrive as Jira tickets.
The data team exports the product schema with column comments, the dbt models with their descriptions and tests, and saved questions with their titles. Warehouse query history reaches back only a limited period, so the team exports what remains and links queries to Jira requests by author and time.
A SQL parser removes literals, and account IDs become consistent tokens. Customer-created custom field definitions are excluded pending counsel's review, and no result rows leave the warehouse. The package notes which queries are linked to a request and which stand alone.
How SourceX approaches schema and query packages#
SourceX treats schemas and query histories as engineering records that usually travel with issues, code and reviews. In the SourceX five-step transaction, the Rights step covers whether schema elements reflect customer configurations, and Preparation covers literal removal and pseudonymization in a delivery copy.
The SourceX Evidence Packet records which sources were included, which transformations were applied and that no result rows were released. In the SourceX Enterprise Data Value Framework, hand-written queries linked to the request and review behind them rate higher on human-generated signal and AI utility than bulk machine-generated SQL, while dense literals raise preparation cost and privacy burden.
Frequently asked questions
Does sharing our schema create a security risk?
A schema can reveal details an attacker might use, such as which tables hold credentials or payment data. Review security-sensitive tables with your security lead, generalize or exclude them, and confirm the delivery copy holds no connection details. Most of the value sits in business tables, not authentication internals.
Do buyers need query results to use the queries?
Not usually. A buyer can run queries against a schema filled with synthetic data to check whether generated SQL is valid and returns sensible shapes. Real result rows add privacy risk with little benefit, and they often contain exactly the customer data the rest of the preparation removed.
Are stored procedures and views licensable too?
They usually are if your engineers wrote them, and they often carry business logic that plain tables do not. Treat them like other code: scan for credentials and literals, check for copied third-party code, and keep the commit history that explains each change.
Are pseudonymized identifiers still personal data?
They can be. Consistent tokens keep joins working, but under some privacy laws pseudonymized data is still treated as personal data because it could be linked back to a person. That is one more reason to keep result rows out and to confine tokens to query text.
Is query history from former employees' accounts licensable?
Usually it is treated as company work product when employment agreements assign work to the company. The query text and metadata may still name the employee as author, so replace user names with stable pseudonymous IDs unless authorship is part of the agreed scope.
Sources
- Google's Sensitive Data Protection API supports de-identification transforms including format-preserving encryption and deterministic encryption, and recommends deterministic encryption over format-preserving encryption where the input alphabet need not be preserved. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.