DBMETA Documentation

Technical Documentation: xo/DBMETA

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

About

dbmeta reads database metadata. Metadata means the description of what a
database contains: its schemas, tables, columns, indexes, constraints,
functions, types, roles, privileges and the rest.

One API answers for every database. A caller asks for tables without knowing
which database answers, and receives the same types whichever one does.

dbmeta reads. It does not change a database and it does not render results.
It is used by usql, a command line client for many databases, and by
dbtpl, a code generator.

PostgreSQL is the model. The shape of every answer follows the metadata
commands of psql, because bringing that experience to other databases
is the purpose of this package.

Installing

go get github.com/xo/dbmeta

dbmeta depends on the standard library and on nothing else. It imports no
database driver and no URL parser. The caller opens the connection with the
driver of its choice and passes it in.

Nothing here parses a connection string, because nothing here opens a
connection. If you want a URL to open a database, use dburl, which
is what the examples below do. dbmeta never sees it.

Using

Import the package and the models for the databases you need:

import (
    "github.com/xo/dbmeta"
    _ "github.com/xo/dbmeta/all"
)

dbmeta asks a database to do one thing, and says so in the type system:

type Queryer interface {
	QueryContext(ctx context.Context, query string, args ...any) (*sql.Rows, error)
}

sql.DB, sql.Tx and sql.Conn all satisfy it. Pass a sql.Tx to read
several catalogs in one snapshot.

Open a connection, read the version, then ask:

db, err := dburl.Open("postgres://localhost/example")
if err != nil {
    return err
}

// dbmeta supplies the version statement, runs it against the connection you
// passed, and parses the answer.
versions, err := dbmeta.PostgreSQL.Version(ctx, db)
if err != nil {
    return err
}

m, err := dbmeta.New(dbmeta.PostgreSQL, versions)
if err != nil {
    return err
}

for t, err := range dbmeta.Tables.All(ctx, m, db, dbmeta.Args{Schema: "public"}.Map()) {
    if err != nil {
        return err
    }
    fmt.Println(t.Schema, t.Name, t.Type)
}

There is one query value per kind of object, such as dbmeta.Tables and
dbmeta.Columns. Name the value and the result type follows from it.

dbmeta.Open does the version and New in one step, and returns the error
when the version cannot be read. Query.Each takes an Args rather than a
map and passes only the arguments the query takes, so one Args serves every
kind of object. All refuses an argument the query does not take, which
catches a misspelled name. Dialect.Pattern turns a psql pattern, such as
public.film*, into a schema pattern and a name pattern, folded as the
product folds a name. See D169.

m, err := dbmeta.Open(ctx, dbmeta.PostgreSQL, db)
if err != nil {
    return err
}
schema, name := dbmeta.PostgreSQL.Pattern("public.film*")
for t, err := range dbmeta.Tables.Each(ctx, m, db, dbmeta.Args{Schema: schema, Name: name}) {
    if err != nil {
        return err
    }
    fmt.Println(t.Schema, t.Name, t.Type)
}

Running the statement yourself Copy Chapter

A caller that prints statements, or that runs them its own way, asks for the
statement instead of the rows:

sqlstr, args, err := dbmeta.Tables.Build(m, dbmeta.Args{Schema: "public"}.Map())

Query.Fields and Query.Params describe what a query returns and what it
takes. dbmeta.Queries lists every query, and Query.Support says whether
this database answers it.

Overriding the version Copy Chapter

The caller chooses the version. dbmeta never detects one behind your back.
Build a version set by hand and pass it to New when a proxy hides the server,
when a compatible product reports a version it does not behave like, or when
there is no server at all.

Iterators hold a connection Copy Chapter

An iterator holds a database connection until it ends. Stopping early, with
break or by canceling the context, releases it.

Do not open a second iterator inside the body of the first. That needs a second
connection and deadlocks on a pool of one. Ask for every row you want in one
call and filter in the loop.

Database Support

A native model reads the catalog the database keeps for itself. A shared model
reads information_schema, which is a smaller answer that many databases have.
It answers 12 object kinds where the native PostgreSQL model answers 65, and
answers none of them completely: no size, owner or access method for a table,
no storage or index detail for a column, no exclusion constraint, no aggregate.

ClickHouse ships an information_schema and the model does not read it. It is
an emulation that reports what the standard names and drops what makes a
ClickHouse table what it is: the engine, the partition key, the sorting key,
the codec per column and the skipping indices. system has all of it.

Cassandra has no information_schema at all and has a native model for the
same reason SQLite and Oracle do. It is the only one here that is not
SQL, and CQL is narrower than the name suggests: it cannot compute, it cannot
express an optional filter, and it cannot order across partitions. D62 holds
what follows from that. usql builds on the shared reader today for
Snowflake, Trino, Databend and DuckDB, which is the evidence for who
the shared model serves.

SQL Server was on that list too. usql reads it through the shared reader with
sequences and constraints switched off and a small plugin for catalogs and
indexes, and the native model here answers 32 kinds instead, including the
sequences and constraints that reader turns off.

COVERAGE.md says what each database answers, what it cannot,
and which analogues were found and rejected. MariaDB answers 30 of the 65 and
MySQL answers 27, because a native model beats the shared one by seventeen.

MariaDB and MySQL share one model. A query written for one of them gates on the
product rather than on the release number, because MariaDB is at 13.0 and MySQL
at 26.7 and neither number says anything about the other. CI runs both products
and a third job compares them against the same schema.

Cassandra and ScyllaDB share one model in the same way. ScyllaDB answers one
kind more, RoleSettings, from the service level attached to a role. D91
records how the model tells the two products apart.

SQLite and DuckDB have no server. Both are libraries, so the release under test
is whichever one the Go driver was built with, neither needs a container, and
neither model carries a version gate.

Every driver the tests use is the one the dburl registry names for that
dialect, because dburl is upstream of dbmeta and of every consumer. The
version can differ and the package must not, because a query that works here
and fails on the driver a consumer opens is a query that does not work. See D52
and D154.

A model ships its queries and a fixture together. The fixture is a known good
schema containing one of every object the queries read, exported so that other
projects can generate against it.

Version Support

Every version sits in one of five tiers. Read the tier before you rely on a
version.

D40 set three of these, D42 added Nightly and D119 added Staged. The first four
are values of container.Tier. Archived is not, because an archived release is
one the list does not name at all.

A Staged release is not supported by dbmeta. It is there so that dbrun can
start a server for a sister project, such as dbimp's drivers, or for a flavor
that a model does not detect yet. It moves to Tested, Nightly or Verified in
the change that adds its model, and takes as its tier the cadence it already
records: Tested, Nightly or Verified. dbrun list --json prints the cadence,
and dbimp runs the tested ones on each push and the nightly ones at night
(D120).

PostgreSQL Copy Chapter

Supported from release 9.6 to release 18, which is ten major versions: 9.6, 10,
11, 12, 13, 14, 15, 16, 17 and 18.

Four releases are Tested: CI starts a real server for each and runs the
integration tests on every change. They are the floor, the ceiling and one on
each side of the middle, which is the smallest set that catches every fault
found so far. Testing only the newest catches two of the six.

The other six are Nightly, and CI runs them once a night. dbrun runs any of
the ten on a development machine.

Every query is executed against a real server at all ten releases by dbrun,
which also checks that the columns returned match the fields
declared and that a field the server is too old for arrives as NULL. The
objects PostgreSQL did not have before release 10 are refused there rather than
returning an empty result:
publications, publication tables, subscriptions, extended statistics and
partitioned tables.

psql itself dropped support for servers below release 10 in PostgreSQL 20.
dbmeta supports 9.6 deliberately, and its queries for that release are
translated from an older checkout.

SQL Server Copy Chapter

Supported on 2017, 2019, 2022 and 2025 in containers, and on 2008R2, 2012,
2014 and 2016 on Windows machines.

All four are Tested, and CI starts a real server for each on every change.
There are only four, and every version gate the model carries sits below all of
them, so there is no older branch that a smaller matrix leaves uncovered.

2017 is the first release with a Linux container. Microsoft shipped SQL Server
on Linux from 2017, so the older releases run on Windows machines that dbrun
builds. They are Verified: a person runs them on a development machine before
a release, and CI never does. The queries carry gates for sys.sequences and
sys.dm_db_stats_properties at 2012 and for sys.external_tables at 2016,
and models/sqlserver/version_test.go checks that those gates resolve. See
D54 and D57.

Design

dbmeta supplies the data and the consumer decides what to show. psql sets
the object model and it does not set the column set, so a query here returns
facts psql does not print where the database can produce them in the same
statement. D47 holds the rule and the cost test.

Read NULLS.md before writing a query for any database. It is
the shortest document here and the one that cost the most to learn.

Everything else is in docs/:

AGENTS.md holds the rules for writing code here, for a coding
agent, with a table saying which document to read for which task.
CLAUDE.md imports it, so that Claude Code reads the same rules.
CONTRIBUTING.md is the same for a person, and shorter.

Testing

container/ names every server release that dbrun starts, as Go data, one
file per product, and container.All joins them. Many are there only for
dbimp's drivers, for the flavors usql reaches, or as emulators of hosted
services, and no model reads them. Those are Staged, and CI does not run them
(D119). Each entry holds the image, the tag, the environment, the readiness
command and the connection string, and it starts nothing: a caller brings its
own podman, docker or Go client, and dbmeta depends on none of them.

for _, s := range container.All() {
	fmt.Println(s.Name(), s.Tier, s.Ref())
}

Run the tests against a release, or a product, or a tier:

cd test && go run ./cmd/dbrun test mariadb-13.0

dbrun test all runs every release. It reads the list from container, starts
each server, waits for it to accept a connection, runs the tests and removes
the container. CI builds its matrix from the same list, and
container/workflow_test.go fails when the two disagree. Nothing else starts a
container, which is D68. docs/DBRUN.md says how to use it.

Every database also answers one checked in expectation. TestConformance
builds the same core schema on every database with a model and compares the
portable facts, so a difference between two families is either fixed or written
down. The relational databases agree on at least 23 of the canonical lines, and
every database agrees on at least 4,
and COVERAGE.md records every difference that is not.

Related Projects

dbmeta is one of a set of packages that each do one part of the job, so that
a client can take the parts it needs.

• usql is a command line client for many databases. It is the reason
  the object model follows psql. USQL.md measures what it
  answers today and what dbmeta changes.
• dbtpl generates Go code from a database schema. It reads the same
  metadata and it can build against the fixtures here. DBTPL.md
  measures the same thing for it.
• dburl parses a database URL and opens a connection. dbmeta never
  parses one, and it never repeats the scheme and flavor taxonomy that dburl
  holds. From v0.29.0 dburl.Scheme describes each scheme as well as parsing
  it, with the Go driver package, whether that driver needs cgo, and whether
  the product is embedded, a server or hosted. That is where to look up a
  driver, and D80 says why dbmeta reads it as a document rather than
  importing it.
• tblfmt renders a result set the way psql does. dbmeta reads
  metadata and does not render it, so a client that wants a table passes the
  rows to tblfmt.

Contributing

Read AGENTS.md first. It holds the rules, including the ones
that are not obvious: the standard library only, no cgo in anything a consumer
builds, no build constraint on an operating system or an architecture, and a
context on every function that reads from a database.

Run the checks before you send a change, with the same flags CI uses:

gofmt -l . && go vet ./... && go build ./... && go test -race -count=2 ./...

To run the integration tests, start a server and point the test module at it:

cd test && go run ./cmd/dbrun test postgres-18

dbrun test tested nightly verified runs every supported release of every
product, which is what has to pass before a release. dbrun test all adds the
Staged releases, which no model reads.

Tests in this module never open a database connection. They render statements,
resolve versions, and read rows from a fake driver replaying recorded data, so
they need nothing installed and they cover releases whose container images no
longer start.

Overview (`docs/decisions/README.md`) Copy Section

Decisions

Every decision this project made is a file in this folder, one per decision,
named by its number and its title. This table is the index. Find the number
here, then open the file.

Each file opens with its status. "Decided" means Ken chose it. "Proposed"
means an agent or a peer session suggested it and Ken has not confirmed it.
"Open" means nobody has chosen yet. A decision that changes an earlier one
says so in its status, as "Amends D50", and the earlier one says it back, as
"Amended by D111". Read the status before the decision.
97 of them amend or replace an earlier one, and a decision read without its
amendment is worse than no decision.

A new decision gets the next number and a file of its own. Add its row here.
TestTheDecisionIndexIsComplete fails when a decision has no row or a row is
wrong, and it prints the row to add. D111 moved the decisions here from one
file.

BACKLOG (`docs/BACKLOG.md`) Copy Section

Backlog

This document lists work that is known and not done. Each item names the
decision or the measurement that found it.

A decision is not a backlog item. It goes in decisions/.
A question for Ken goes at the end of PLAN.md, under Open questions
for Ken. When an item here is done, delete it, and record in decisions/
anything that was decided on the way (D110).

Servers Copy Chapter

Finish the native clients of dbrun cli Copy Section

D236 added dbrun cli. Three things are left:

1. Ken chose on 2026-10-22 that cqlsh and sqlplus keep the password as an
   argument, with a note, and that dbrun writes no temporary file for them.
   Nine clients take it that way: sqlplus, cqlsh, mongosh, hdbsql,
   arangosh, rqlite, cbq, ksql and exaplus. The last seven need a
   measurement of what each client offers.
2. Only psql, mysql and mariadb were run, and psql on Redshift. Run the
   other clients against a server and correct the forms that are wrong.
3. Redshift, Neon and PlanetScale have a client. The other hosted services have
   none, and each one says why in hosted/hosted.go. A hosted service has one
   credential, so --as is not supported. Running a client inside the
   container when the host has none is open. Ken chose host only for now.

Decide the pins that need Ken Copy Section

D235 moved most pins and left four for Ken. The first is Solr 9.11.0, a new line
that was rebuilt on 2026-10-17, and the rule in container/solr.go does not say
whether it replaces 9.10.1 or sits beside it. The second is SingleStore image
0.2.86, which needs dbrun to measure its engine before the pin moves. The third
is the MariaDB 10.6 floor, because the vendor ended it in 2026-07 and the image
is still patched. The fourth is the Cassandra 3.11 floor, which was not rebuilt
since 2025-11-14.

ClickHouse 25.3 is the next pin to look at, because it was not rebuilt for eight
and a half months. The comment on SQL Server 2017 in container/sqlserver.go is
also stale. It says the image is built on Ubuntu 16.04, and the image now reports
Ubuntu 18.04.

Find why the Hive setup fails on a slow machine Copy Section

The Hive setup fails on a GitHub runner, soon after HiveServer2 first answers,
with a SerDeException: "proto.class has to be set". It comes from one of the
PROTO_ tables at the end of the schema script, which dbmeta does not read.
It never failed on a development machine. D105 runs the setup again after a
failure, and D107 made the script safe to run twice, so a retry can get past
it. The cause is not known.

Read the log when Oracle 21c does not answer Copy Section

oracle-21c did not answer in five minutes on one CI run, and it answers in
under a minute on every other run. The cause was not recorded. D105 now
prints the last 20 lines of the container's log when a server never answers.
When it happens again, read that log and decide whether the entry needs a
change.

Find why oracle-26ai and QuestDB failed in CI Copy Section

On 2026-10-08 the first CI run on 90d0261 failed two jobs, and both passed when
rerun, so neither touches that change. oracle-26ai failed in the image's
setup, when it reset the SYSTEM password, with ORA-65048 on ALTER USER SYSTEM.
It failed again on 76f266b the same day, at the same statement, with ORA-04021,
a timeout while it waited to lock an object. So the setup of the 26ai image
races a job that the database starts itself, and two runs in about thirty
lost. questdb-9.4.3 failed once, in TestQuestDBFixtureObjects at
questdb_test.go:216, with the view recent listed and the view book
missing. The cause of neither is known. For Oracle, read what the image runs
at start and whether dbrun can wait for it, or start the server again when
that statement fails.

questdb-9.4.3 and questdb-10.0.1 each failed once on 2026-10-10, in
TestPrivilegeParity for the read-only principal: the tables query read "the
same rows with different values". The cause was Table.Rows (D207), which reads
table_row_count: a WAL table applies its writes later, so the count differed
between two reads, and the setup waited only for the table book. The setup now
waits until wal_tables() shows no table with sequencerTxn above writerTxn.
If the failure returns, read the log first.

Find why Databend's first start can fail Copy Section

The first start of databend-1.2.948 after the pull of the image did
not answer. The image's bootstrap script starts the query server one second
after the metadata server, and the metadata server was still waiting to become
the leader, so the query server gave up with "cannot connect to
http://0.0.0.0:9191". It did not happen again in four fresh starts (D112). If
it comes back in CI, the entry can start the two servers itself and wait for
the metadata server between them.

Move the ceilings that move Copy Section

Three ceilings move faster than the others. Databend publishes a weekly
release almost every day, ArangoDB's release is the newest 3.12 patch, and
Neo4j's is the newest monthly release (D106, D112). When a newer release is
published, replace it in the file in container/ and in the row in
EVALUATION.md.

Consider a SQL layer for what a product does not answer Copy Section

This is not a priority (D166). Apache Pinot keeps its catalog only in the
Controller's REST API, and its Broker's SQL has no information_schema, no
SHOW and no DESCRIBE, measured on 1.4 and 1.5 on 2026-10-01. InfluxDB names
its release only in GET /ping. A generic SQL layer, in a driver or beside
one, can answer such statements, for example SHOW TABLES, DESCRIBE and
SELECT version(), from what the product does expose. If Ken takes it up,
a Pinot model can walk those statements, as Impala's does (D146), and the
InfluxDB models can read the release with a statement.

Finish what D204 left open for Redshift Copy Section

A grant of a table to a role is not in Privileges, because only
SVV_RELATION_PRIVILEGES lists it and that view shows a user only the rows of
that user. The routine
parameters, the types, the casts, the aggregates and the operators have a
source in pg_catalog and are not read. The partitions of a Spectrum table
(SVV_EXTERNAL_PARTITIONS) are not read, because the Glue table of the fixture
has none. A run with a partitioned Glue table finishes them (D221).

Read what Snowflake answers and no kind holds Copy Section

Measured by D203 and left out. Roles is answerable by SHOW ROLES, and Role has
bools that Snowflake has no source for. Indexes and IndexColumns are
answerable by INFORMATION_SCHEMA.INDEXES and INDEX_COLUMNS for a hybrid table,
which a trial account refuses to make, so no row was read. The same account
refuses masking policies, row access policies and materialized views. A run on
an Enterprise account with a hybrid table and a row access policy finishes
them.

Settle the size and the rows of CrateDB and QuestDB Copy Section

D207 measured it. The sources for the size and the row count of a CrateDB table
(sys.shards, and pg_class.reltuples) and of a QuestDB table
(table_storage()) cost a scan of the whole catalog for each read.
Table.Size and Table.Rows are left NULL for CrateDB, and Table.Size for
QuestDB. If either product makes the join follow the filter, the fields can be
added. Redshift reads them only on request (D212, D232).

Read the options of a Redshift table without SVV_TABLE_INFO Copy Section

D232 left Table.Options NULL for a Redshift table and a view by default,
because the distribution style and the sort key came from SVV_TABLE_INFO. The
columns reldiststyle of pg_class and attisdistkey and attsortkeyord of
pg_attribute hold the same facts, and every user can read them. They were not
measured. If they answer in one statement with a bounded plan, the options can
be read with no grant, and only the size and the rows need WithTableInfo.

Read the settings of a CrateDB user Copy Section

sys.users.session_settings is the analogue of RoleSettings. One statement
returns the object as JSON text and not as name=value lines, because CrateDB
cannot read the value of a key that the statement does not name. A later
release can change that.

PostgreSQL model Copy Chapter

Read the sections of `\d` that no kind answers Copy Section

D201 left four things out. psql's Referenced by section lists the constraints of
other tables that name this one, and Constraints filters by the table that owns
the constraint, so a kind or a filter on confrelid is needed. The token types
that \dFp+ prints come from ts_token_type of the parser. The index footer of
\d NAME prints the tablespace of each index. Subscriptions lists the
subscriptions of every database, and psql narrows to the current one.

Make the owner of a sequence cost what the rows cost Copy Section

The owned_by column of Sequences reads pg_depend by objid alone, and the
index of that catalog starts with classid. Each sequence scans the table, so
5005 sequences took 5.9 seconds on release 15, and one sequence by name takes
0.2 ms. D201 measured it. The fix is to add the class of the sequence and of the
table to the subselect. Measure it before and after, on a catalog of thousands
of sequences.

Consumers Copy Chapter

Move the rules of the products with no model out of usql Copy Section

ODBC, csvq and Cosmos keep rules of their own in usql's drivers, such as
ODBC's usql_trim, csvq's SHOW routing and the trailing semicolon Cosmos strips,
and have no model here, so D143's Info fields do not reach them. Athena has a
model now (D222), and its usql driver keeps the same rule for the semicolon.
D230 moved the placeholder, the version text and the query and scan flags.
What is left is these rules, the InfluxDB and csvq versions, and the semicolon.

usql reads metadata through dbmeta Copy Section

usql's W21 moved its describe commands, its version and \password onto
dbmeta, and its W31 wires up every psql describe command in
COMMANDS.md. Both are staged in usql and not committed.
When W31 lands, update the column "usql today" in COMMANDS.md, and what
USQL.md says usql answers.

Move usql's \copy statements here Copy Section

D230 moved the placeholder of \copy here, as Dialect.Placeholder. The probe of
the columns of a table, SELECT * FROM t WHERE 1=0, is still in usql's drivers.
It is not a read of the catalog, so it needs a decision beside D56 before any
of it lands here.

dbtpl reads metadata through dbmeta Copy Section

DBTPL.md holds which of the nine reads dbtpl needs each model
answers, and whether dbtpl can generate from each database. dbtpl does
not read dbmeta yet.

Models Copy Chapter

Read the size and the clustered flag of an index Copy Section

D205 left Index.Size and Index.Clustered NULL on MariaDB and MySQL. The
sources are mysql.innodb_index_stats (the size in pages, a table of the mysql
schema) and INNODB_INDEXES or INNODB_SYS_INDEXES (the type, where 1 is the
clustered index). Both refuse a user without the PROCESS privilege or SELECT on
the mysql schema, as measured on MariaDB 12.3. They can come back as a
fragment that a parity scene marks as refused for the grantee, if Ken wants the
fields more than the statement that answers for every principal.

MariaDB puts the compression comment in the data type Copy Section

Column.DataType is COLUMN_TYPE, and MariaDB writes /*M!100301 COMPRESSED*/
into it for a compressed column, so the type reads text /*M!100301 COMPRESSED*/
on 12.3. D205 reads Column.Compression from that comment and did not change
DataType. A caller that compares types sees the comment.

Vitess reads the size of one tablet Copy Section

Table.Size and Rows on Vitess are the numbers of the tablet that vtgate
picks, and a keyspace with several shards holds the rest elsewhere. A sum over
the shards needs vtgate to run one statement on every shard, which it does not
do for information_schema.

A Validated field on Constraint Copy Section

D206 fills Constraint.Enforced for SQL Server and Oracle as "the server checks
a new row". Both products also say whether the rows that were already there are
known to satisfy the constraint: is_not_trusted on SQL Server and VALIDATED
on Oracle. PostgreSQL has convalidated. No field carries it on Constraint.
Add Validated sql.Null[bool] to the root type and fill it in the three models.
NotNull.Validated already exists.

Oracle sizes of partitioned tables and subpartitions Copy Section

PartitionedTable.DirectSize and TotalSize are NULL on Oracle, and
Partitions has no rows for subpartitions (D206). A size needs the connected
user and a sum over USER_SEGMENTS. A subpartition needs a kind that is not a
LONG in a UNION.

Settle the size and the rows of a Vertica table and the encoding of its columns Copy Section

D208 measured it. The size and the rows of a table are in
v_monitor.projection_storage and the encoding of a column is in
v_catalog.projection_columns. A subquery on either for every table or column
made a read of one table 3 to 22 times slower, and the cost grew with the
catalog. Table.Size, Table.Rows and Column.Compression are NULL. A
projection of a replicated table is also repeated on every node, so a sum of
rows is not the rows. If a later release gives a view that follows the filter,
the fields can be added.

Options and size of a SQLite table Copy Section

D208 leaves Table.Options NULL on SQLite. pragma_table_list has the strict
and the WITHOUT ROWID flags, and joining it for every table grows with the
square of the catalog. A shadow table is listed as a table, and
pragma_table_list calls it shadow. Ken decides whether the type changes.
Table.Size needs dbstat, which scans the file and is not in the mattn
driver.

Row security for Vertica, ClickHouse and Databend Copy Section

Table.RowSecurity is NULL for all three. The Vertica and ClickHouse sources
(access_policy and row_policies) are refused to or filtered for a user who
is not an administrator, and a flag that reads false for that user is a wrong
answer. Databend 1.2.951 has no catalog for its row access policies. A later
release can add one.

The SETTINGS clause of a ClickHouse table Copy Section

The settings of a MergeTree table, such as index_granularity, are in
engine_full as text after SETTINGS. A statement cannot split them, so
Table.Options has the clauses that have a column of their own.

SAP HANA size and row count Copy Section

Table.Size, Table.Rows and Index.Size are NULL on SAP HANA (D209). The
sources are SYS.M_TABLES, SYS.M_RS_INDEXES and SYS.M_CS_INDEXES, and any
user reads them for the objects it can see. The planner reads one row when the
filter is a literal, a plain = ? or a plain LIKE ?, and reads every table
when the filter is the (? = '' OR x LIKE ?) form that all the models use. Fill
the three fields when one statement can pass a pattern that the planner pushes
down, and measure with 3000 tables.

Exasol left join to the object sizes Copy Section

Table.Size on Exasol joins EXA_ALL_OBJECT_SIZES, which costs 85 ms at 3000
tables for one table, and 41 ms with the fixture only (D209). An inner join
costs 10 ms and can drop a table that a user sees in EXA_ALL_TABLES and not
in EXA_ALL_OBJECT_SIZES. Run the parity targets with an inner join, and keep
it if the rows do not change.

Spanner table and index size Copy Section

Table.Size, Index.Size and Tablespace.Size are NULL on Spanner (D216,
D219). The source is SPANNER_SYS.TABLE_SIZES_STATS_1HOUR. On 2026-10-10 a
table with 2000 rows of 500 bytes and an index, in a named schema and in the
default schema, was in Cloud Spanner for 35 minutes and the view held only the
row unknown_table_name with 0 bytes for the two hourly intervals after it.
Cloud Spanner needs more time or more data, and the cause is not known. Check
again with a table that is older than a few hours, and read how the view names a
table in a named schema, which this measurement did not show.

Spanner objects that no kind holds Copy Section

Spanner has objects that the 65 kinds have no place for (D216). A property graph is
in INFORMATION_SCHEMA.PROPERTY_GRAPHS as one JSON value, a model is in MODELS
and refused by Spanner Omni, a placement is in PLACEMENTS and needs an instance
partition, a table synonym has no kind but is a Table of type synonym, and a
proto bundle is one binary descriptor in SCHEMATA. Ask Ken whether any of
them is worth a kind, with the cost test of D47. The ON UPDATE expression, the
hidden flag and the identity kind of a column, the options of a sequence, and
the security type of a view are columns of INFORMATION_SCHEMA that no field holds
either.

Spanner index definition Copy Section

Index.Definition and Index.Using are NULL on Spanner (D216). INFORMATION_SCHEMA
keeps the parts of an index and not its statement. A statement can build
CREATE INDEX from INDEX_COLUMNS, INDEXES and INDEX_OPTIONS with one
aggregate, and the work is to write it and to measure it on a large catalog.

BigQuery grants on a table and a dataset with no table Copy Section

Privileges reads the IAM bindings of the dataset only, because OBJECT_PRIVILEGES
answers one object at a time, and a table has a row only if somebody sets a binding on
it (D226). Set one on a fixture table and measure the rows. Schemas, CurrentSchema and
Privileges read no row for a dataset with no table or view, because @@dataset_id is
NULL and the tables of the dataset name it. A dbimp driver that tells the dataset of the
connection to a statement removes the limit.

BigQuery on a large catalog Copy Section

No catalog of thousands of tables was built on BigQuery, because each table is a
job of a second or more and each INFORMATION_SCHEMA read bills 10 MB (D220). Build
one in a loop, run a dry run of each statement, and read the time of the job, to
check the cost test of D47.

BigQuery generated columns and row access policies Copy Section

BigQuery refused every generated column that the fixture tried, with "Unsupported
generated column expression", so the mapping of Column.Generated is not
measured. A row access policy exists, and no view lists it: the views that DeepSeek and
Gemini named answer not found (D226). See D220.

Run the Exasol Community Edition machine on the driver of dbimp Copy Section

D234 moved the Exasol tests to the driver of dbimp, which dbimp tagged in v0.20.0. The
Verified Community Edition machine exasol-2025.2.1 was not run on it, and the two
exasol@2025 sections of parity.txt were edited by hand. Run dbrun test exasol-2025.2.1 on a
development machine and read the diff of the goldens.

Cosmos DB, one index for each entry of the policy Copy Section

Indexes for Cosmos DB is one row for each container, the policy (D233). One row for each
entry, with a composite index as one row, needs a hook that expands a row into several
objects, or a way to drop the rows of a composite index after the first. Both change the
root package, which is Ken's decision. IndexColumn has no field for the kind of an entry,
so Expression carries it. A Kind field on the index column is cleaner. The status
and the parents of a partition key range have no field on Partition either.

Measure what the Cosmos DB account cannot build yet Copy Section

The account has no vector search, no change feed of all versions, no analytical store and
no region to write to but one, so a vector embedding policy, a vector index, a change feed
retention, an analytical time to live and a custom conflict resolution policy were never
measured, and the autoscale columns of $offers were not either. The statements read them
by the names that Microsoft documents, and they are NULL on this account. If an account
gets one of those capabilities, extend the fixture and the tests of Tables and of the index
columns. The vector rows of $index_paths were not read, for the same reason.

Databricks table size, defaults and checks have no source Copy Section

Databricks answers 17 of the 65 kinds (D224). The size, the row count, the location and
the clustering columns of a table are in DESCRIBE DETAIL. A column default, an identity
column, a generated column and a CHECK constraint are in SHOW CREATE TABLE and SHOW
TBLPROPERTIES. All of them are statements that a SELECT cannot read, and INFORMATION_SCHEMA
reports a default as NULL and an identity column as NO. D146 allows a walk for four
products, and Databricks is not one. A walk costs one statement for each table, and the
warehouse is shared and has a daily quota. Ken decided on 2026-10-11 that Athena gets no
walk, and Databricks follows the same rule. Ask Databricks and dbimp for a relation that holds them: system.information_schema.tables
has no size column on the release that was measured.

Databricks on other principals, a catalog of thousands of tables and a cluster Copy Section

The reader of the test account sees no routine and no volume, because it holds no
EXECUTE and no READ VOLUME. A principal that holds them was not measured. No catalog of
thousands of tables was built, because the free edition has a daily quota of compute, so
the plan of each statement against a large catalog was not checked. The version of a
cluster, dbr_version, was not read, because the account has a warehouse only. The
connection, share, external location and storage credential relations were read on an
account that holds none, so ForeignServers was shown to run and the others were left
out (D224).

Athena table comments, partitions and functions have no source Copy Section

Athena answers 8 of the 65 kinds (D222). The comment and the location of a table,
the values of a partition and the function list are behind SHOW CREATE TABLE, SHOW
TBLPROPERTIES, SHOW PARTITIONS, DESCRIBE and SHOW FUNCTIONS, which a SELECT cannot
read. D146 allows a walk for four products, and Athena is not one. A walk costs
one statement for each table, and each Athena statement is a job of one to six
seconds. Ken decided on 2026-10-11 that Athena gets no walk. The hidden tables "t$partitions",
"t$properties" and "t$files" are per table too.

Athena on a large catalog and on other workgroups Copy Section

No catalog of thousands of tables was built on Athena, because a table is a job of
several seconds. INFORMATION_SCHEMA scans no data, so the cost of a read is time
and not money. The engine version of the workgroup is not read. A test of the other
principals that an account can hold, such as a role with Lake Formation grants that
hide a table, was not made (D222).

COMMANDS (`docs/COMMANDS.md`) Copy Section

psql Commands and the Go API

This maps every psql metadata command to the dbmeta Go value that answers
it. It exists so that wiring usql up later is a lookup rather than a reading
exercise.

The mapping was taken from exec_command_d in src/bin/psql/command.c, which
is the dispatcher psql itself uses, so the command spellings and the grouping
are psql's rather than a reconstruction.

How to read it Copy Chapter

Each row gives a command, the Go value that answers it, and the type that value
yields. Every value is a *dbmeta.Query[T], so the call is the same shape
whichever row you are on:

for v, err := range dbmeta.Tables.All(ctx, m, db, args) {
	// v is a dbmeta.Table
}

A caller that wants the statement rather than the rows calls Build on the same
value, and Fields, Params and Support describe it. See the package
documentation.

usql today says whether usql currently implements that command at all. It
implements eleven of them, so most of this table is capability that exists in
dbmeta and has no consumer yet.

Relations Copy Chapter

\dt, \dv and \dm are one query in psql and one here. Narrow with the
types argument rather than with a different value: a table, a view and a
materialized view differ by Table.Type.

Describing one relation Copy Chapter

\d NAME is not one query. psql assembles it from several, in
describeOneTableDetails, which is the largest entry point in describe.c and
carries 21 of its 68 version gates. dbmeta keeps them separate, because a
caller usually wants one of them.

To reproduce \d NAME, read these with the same Args{Schema, Parent}:

The sections that \d+ NAME adds are read the same way. Each takes the
parent filter, so one table costs one small statement. D199 holds the types
and the cost.

Routines and types Copy Chapter

\dfn, \dfp, \dft and \dfw narrow \df to normal functions, procedures,
triggers and window functions. They are the same query narrowed by
Function.Kind, not separate values.

Users and privileges Copy Chapter

\z and \dp are the same command in psql.

The two parts of \dp that psql prints as text are rows too. D201 holds the
reasons.

Storage and the server Copy Chapter

Foreign data Copy Chapter

ForeignOption.Quoted is the option as psql prints it inside the parentheses.
Options of each kind is the catalog text and keeps its meaning.

Replication Copy Chapter

The other columns of \dRs+ are fields of Subscription. Only a superuser can
read the connection string, so it is a kind of its own. D201 says why.

Text search Copy Chapter

Operator families Copy Chapter

Extensions Copy Chapter

What has no mapping Copy Chapter

Two gaps, in opposite directions. One is now closed.

\ss is a usql command with no psql equivalent. It shows column statistics
values, and psql has never had such a command: no "ss" has ever appeared in
command.c and describe.c has never read pg_stats. Jan Was added it to
usql in 2021, implementing it for PostgreSQL from pg_stats and for Trino
from SHOW STATS FOR, and DuckDB gained it later with the same Trino syntax.

dbmeta.ColumnStats now answers it. The decision it needed was which shape to
take, because the databases disagree: PostgreSQL reports null_frac,
n_distinct and most_common_vals, Trino and DuckDB return the result of
SHOW STATS FOR, MariaDB keeps mysql.column_stats with its own columns, and
MySQL 8 keeps a JSON histogram under a view named like MariaDB's and holding
something else. D9 does not settle it, because PostgreSQL's shape is not
obviously right for a histogram.

The shape taken is PostgreSQL's, with every field nullable. A database that
computes something reports it and a database that does not reports absent,
which is the padding rule applied to a kind rather than to a release.
PostgreSQL, MariaDB, SQL Server, Oracle, SAP HANA, Apache Hive, CrateDB,
Databend, SingleStore and Impala answer. MySQL, SQLite and the other models
report ErrNotSupported, because none of them has a width, a null fraction or
a distinct count to give. A row of absences is worse than no row. See
COVERAGE.md.

\sf and \sv show the source of a function or a view. They live outside
describe.c and are not part of the 49, so they are not in this table.
Function.Definition answers the first, and dbmeta.Views answers the
second. Function.Source holds the body where a product keeps one apart from
the statement (D147).

The kinds with no psql command Copy Chapter

Seven object kinds here answer no psql command. They exist because usql and
dbtpl were measured and needed them, and D47 allows them: psql sets the
object model and does not set the column set.

In each of the first three the prose and the parts are both available. The
parts are authoritative and the prose is what psql prints, so a client
matching psql output does not have to rebuild the string for every dialect.

Two fields follow the same rule. Column.PrimaryKey is in the row MySQL and
SQLite already select and costs PostgreSQL one join. Function.ID identifies a
routine where the name does not, and RoutineParameters carries the same value
so that the join is one expression everywhere.

Wiring usql up Copy Chapter

An agent doing that work needs three things beyond this table.

The caller supplies the dialect and version. usql already reads a version
string per driver, and dbmeta.Dialect.Version replaces that. The dialect is
dburl.URL.Dialect, which dburl sets when it parses a URL, from v0.32.0.

Read URL.Dialect and never URL.Driver. dburl registers a scheme per Go
driver, so URL.Driver names the driver: pgx or moderncsqlite,
and from dburl's D22 pgx for postgres:// too. None of those is a dialect
here. URL.Dialect is postgres or sqlite3 for each of them,
because dburl holds that taxonomy and hard rule 1 keeps it out of dbmeta.
D99 in decisions/ has it.

The flavor needs nothing. dbmeta reads it from the server rather than from
the URL: models/mysql sets the mariadb key when SELECT VERSION() carries
the suffix, so a caller passes the mysql dialect for both products and never
has to say which. A product that speaks another product's protocol is not a
flavor. From dburl v0.36.0, cockroachdb, cratedb, redshift, memsql,
tidb and vitess each arrive with a dialect of their own, and a model for
one of them shares the statements of the model it imitates where they answer
(D123, D125).

Query.Support decides whether to offer a command. It returns NotBuilt when
the model was left out of the binary by a build tag, NotSupported when the
database has no such object, and TooOld when the product has the object and
this release of it does not. Those are three different messages to a person.

Rendering stays in usql. D5 keeps the tblfmt writer there, so the loop is
to read rows from a Query and hand them to the existing writer. The old
Reader and Writer interfaces do not carry over. usql writes no new
reader until it reads dbmeta (usql D3).

CONTAINERS (`docs/CONTAINERS.md`) Copy Section

Adding a Container or a Machine

This document tells you how to add a server that dbrun can start: a new
release of a product that is already listed, a new product, an image that this
repository builds, or a virtual machine. DBRUN.md tells you how
to use dbrun once the entry exists, and its rules for a shared machine apply
to every step here.

A server that dbrun starts is data in the Go package container. It is the
only list of the releases that dbrun starts, whether dbmeta is tested
against them or they are Staged. dbrun and the CI
workflow both read it, and tests fail when either one drifts from it (D42,
D69). The package starts nothing and imports no container client.

Adding a server is one step of adding a database. DIALECT.md
holds the rest, and its step 4 points here. Another repository that needs a
server, such as dbimp or a driver, gets its entry here too, through a dbmeta
session or through Ken. Such an entry is Staged while no model reads it, so
dbmeta's CI does not run it, and the other repository runs it with
dbrun test staged or by name (D119).

Rules Copy Chapter

1. Add the entry to container/ before anything else that needs the server.
   Nothing else starts one (D68).
2. A new product needs Ken's agreement first. D66 holds the order for a dbmeta
   model, and dbimp's order holds it for a server that one of its drivers
   needs (D112, D113). D90 says which products qualify.
3. Choose the releases with EVALUATION.md, and record the
   floor, the ceiling and which step decided in the doc comment of the file.
4. Name every release in one of the tiers Tested, Nightly, Verified or
   Staged. CI runs the first two, and a person runs the third before a
   release. A release that no model reads is Staged, and CI never runs it.
   Add it with staged rather than add, and give it the cadence that it
   takes when a model reads it, Tested, Nightly or Verified. dbimp runs its
   Staged releases by that cadence, and it becomes the tier when the model
   arrives (D120).
   TestAReleaseIsStagedExactlyWhenNoModelReadsIt holds that a release is
   Staged exactly when no model reads it (D119).
5. Publish one port, the one the tests connect to. If a client needs a second
   interface of the same server, set second to its port inside the
   container. dbrun publishes it on the first host port plus 1000, and the
   URL computes it with container.SecondHostPort. QuestDB does this for its
   PostgreSQL interface, and Pinot for its controller (D124). dsn --json
   prints the address in the secondAddress field. Any other interface, such as Couchbase
   Analytics, is not reachable from the host.
6. Use container.Password for the administrator. Use another password only
   when the product cannot take one at start, and say why in the file.
7. Give the server container.MemoryLimit, which is 4 GB. Ask for more only
   after you measured the product needing it, and write the measurement beside
   the number, as SAP HANA does.
8. Write a readiness check that passes only when a test can connect and log
   in as the user the tests use.
9. Make the setup, Init, safe to run twice, because start runs it every
   time. Check before you create. start also runs it again after a failure,
   up to three times (D105).
10. Pin an image by its digest as well as its tag when somebody other than the
    vendor built it (D88).
11. Read an image without starting a container. Use
    podman image inspect for its entrypoint, ports and environment,
    and podman unshare sh -c 'podman image mount ' for its files.
12. Before you finish, start the server, stop it, start it again, and remove
    it. A second start is a different path from the first. It found two
    faults in the Couchbase entry (D96).
13. Check the manifest format of an image that somebody other than the
    vendor pushed. CI runs docker, and the Docker on GitHub's runners refuses
    a Docker image manifest of schema 1, which podman still pulls. Such an
    image is copied into docker.io/usql with
    podman push --format v2s2, which Ken does, because it needs his login
    (D100).

A new release of a product Copy Chapter

1. Find the tag on the registry and check that the image is still rebuilt,
   with the command in step 2 of EVALUATION.md. If the product's images are
   never rebuilt, apply the rule under step 2 for such a product instead
   (D112).
2. Add the release to the list of its product in container/.go,
   with its tier. list.add takes the tier and the releases, and list.on
   changes one release where the product differs from itself.
3. If the release moves the floor or the ceiling, update the doc comment of
   the file and the row in EVALUATION.md.
4. If README.md has a tier table for the product, add the release to it.
   TestTheReadmeTierTablesMatchTheList fails until you do.
5. Run the checks under Check it.

Do not edit the CI workflow. Its matrix comes from the list (D69).

A release added to the list moves the host port of every server after it,
because a port is 55000 plus the place of the server in container.All. A
container that another session built before your change keeps its old port.
dbrun start rebuilds it and dbrun status reports it, so tell the person
that the ports moved.

A new product Copy Chapter

1. Ask Ken whether the product is next.
2. Choose its releases with EVALUATION.md, and add a row to the table
   Databases evaluated so far. TestEveryProductIsEvaluated fails until the
   row exists.
3. If dburl names a scheme for the product, add a constant to the Dialect
   block in dialect.go, with the dburl driver name, if dbmeta has none yet.
   If the server is for a dbimp driver whose name dbimp has not settled,
   leave dialect empty. dbrun then names the test variable for the
   product, such as DBMETA_PINOT (D112).
4. Read the image, as rule 11 says. Find the port the tests use, the
   administrator, how a password reaches it, the settings the tests need, and
   the tools inside it that a readiness check or a setup can run.
5. Write container/.go. It holds a doc comment, the product
   value, and the list of releases. The field reference below says what each
   field is for, and container/couchbase.go is a short example with a setup.
6. Add the list to All in container/container.go, at the end, so that no
   running server gets a new port.
7. If the product has no shell to run a readiness check, leave ready empty.
   dbrun then connects from the host through the driver in the drivers
   map in test/cmd/dbrun/test.go, which needs an entry for the dialect and
   a dbmeta model, because it runs the version query. A product with no model
   needs a ready command.
8. Add the administrator to the credentials table in DBRUN.md. If the
   setup, the start command or the image creates an ordinary user, declare it
   in users, so that dsn --json prints it. container/couchbase.go does
   this.
9. Set client to the native command line client of the product, or to
   none with the reason. TestEveryServerNamesAClientOrSaysWhy fails until
   it is set. Put the password in an environment variable of the client where
   the client has one, and add the product to argvPassword in
   container/client_test.go and in test/cmd/dbrun/cli_test.go only when it
   has none (D236).
10. Run the checks under Check it.
11. Write a decision in decisions/ for anything you chose rather than found,
    such as a setting you turned on or a user you created.

An image this repository builds Copy Chapter

Build an image only when the published one cannot do what the tests need and
no setting or argument can change it. Cassandra's image refuses a user
defined function, a materialized view and a role, and Oracle publishes no free
19c image, so both are built. D118 added more: an image with no shell, such as
the Cloud Spanner emulator's, a product that publishes a jar and no image,
such as H2 and Fuseki, and two programs that must run in one container, such
as PostgREST with PostgreSQL and ksqlDB with Kafka. D145 added Impala, whose
four Apache images are built into one.

1. Write test/cmd/dbrun/image/.Containerfile. It takes the release
   as the build argument RELEASE. Check the result in the build itself, as
   the Cassandra file does, because a sed that matches nothing changes
   nothing and reports nothing.
2. Name the image localhost/dbmeta/ in the entry. dbrun embeds
   every file in that directory and builds the one named for the product,
   so nothing else changes. TestEveryContainerfileHasItsImage fails when a
   file and its entry disagree. Oracle 19c keeps localhost/oracle/database,
   the name Oracle's build script gives it, and has its own build.
3. Keep the password out of the Containerfile. Package the program there,
   and configure it in the entry's command, where container.Password is.

start and test build a missing image. dbrun build <name> builds it again,
which is what you run after you change the file.

A virtual machine Copy Chapter

A machine is a container.Machine. dbrun provisions it once and keeps it,
because building it takes an hour or more. Its tier is always Verified,
because CI cannot run one. It has a fixed port of its own, and its screen
viewer has a second.

For a SQL Server release that has no Linux image, 2008 R2 to 2016, follow
WINDOWS.md. The entry is a WindowsSpec in
container/windows.go, and dbrun provision <name> builds it (D57).

For a vendor's appliance, such as the Exasol Community Edition, the entry is an
ApplianceSpec in the product's own file. It names the file the vendor
publishes, its SHA-256, the page to download it from, the disks in it, and
its memory and processors. Nothing here can download it, so a person does, and
dbrun provision <name> --from <file> checks and imports it (D85, D86).

Name every Verified release in COVERAGE.md.
TestEveryVerifiedReleaseIsDocumented fails until you do.

An embedded database Copy Chapter

An embedded database has no entry in container/, because it has no server
(D42). A model that declares itself embedded gets a dbrun entry by itself.
If the database has no model yet, add it to unmodeled in
test/cmd/dbrun/target.go, with its dialect in dialect.go as dburl names
it, and remove it from there when its model is written (D116). If it starts
from sample files, as csvq does, put them in test/cmd/dbrun/sample/<name>/.

Field reference Copy Chapter

The fields of product in container/container.go, which list.add copies
into each release:

Readiness checks and setups that went wrong Copy Chapter

Each of these was a real fault. The right form is what the entry does now.

Check it Copy Chapter

Run the tests of the list from the root of the repository, and then the rest
from the test directory:

go test ./container/...
cd test
go run ./cmd/dbrun list <product> --releases
go run ./cmd/dbrun start <name>
go run ./cmd/dbrun stop <name>
go run ./cmd/dbrun start <name>
go run ./cmd/dbrun test <name>
go run ./cmd/dbrun remove <name>

Then run the checks in AGENTS.md under Before you commit.

The tests that catch a skipped step Copy Chapter

COVERAGE (`docs/COVERAGE.md`) Copy Section

What Each Database Can Answer

dbmeta asks every database the same 65 questions. PostgreSQL answers all of
them, because PostgreSQL is the model. No other database answers all of them,
and this document says which ones each database answers, which ones it cannot,
and why.

Fifty eight of the questions come from psql. The other seven exist because a
consumer needs them and psql has no command for them: the columns of a
constraint, the parameters of a routine, the labels of an enumerated type, the
statement a view selects, the statistics over a column, the schema an
unqualified name resolves in, and the user the connection is authenticated as.
D47 sets the rule for adding one, and D55 added the last.

A question that a database cannot answer returns dbmeta.ErrNotSupported. It
never returns an empty result. Those are different facts and a caller has to be
able to tell them apart: an empty result means the server holds none of that
object, and ErrNotSupported means the server has no such object at all.

Read COMMANDS.md for the psql command that each Go value answers. Read
D43 in decisions/ for the rule about finding these analogues in the first place.

Adding a database means adding a section here. DIALECT.md holds
every step and this is one of them, so read that first if you are adding one
rather than reading one.

The count Copy Chapter

The shared information_schema model answers twelve: tables, schemas,
columns, functions, privileges, constraints, sequences, constraint columns,
routine parameters, views, the current schema and the current user. It is the floor. A native model
exists to beat it, and models/mysql beats it by seventeen.

Four of those twelve arrived with the kinds D47 added, and they arrived for
free: the standard defines key_column_usage, parameters, views and
schemata, so every database close to the standard answers them.

PostgreSQL Copy Chapter

PostgreSQL answers all 65 questions on release 18, and 64 on 10 to 17, where
NotNulls is refused because the release does not name a NOT NULL
constraint. Release 9.6 answers 57. It also refuses publications, publication
tables, subscriptions, subscription connections, statistics objects,
partitioned tables and partitions, which arrived in release 10. Fields that
psql prints for the describe commands arrived in D198, D199 and D201, and a
release below the one that has the source answers NULL for them.

PartitionedTable.Type and Privilege.Type say partitioned table for a
partitioned table, and PartitionedTable.Type says partitioned index for a
partitioned index (D201).

Table.Rows is the estimate in reltuples. It is 0 before the first analyze
on a release below 14 and -1 from 14. Table.Type says partitioned table for
a partitioned table (D198).

MariaDB and MySQL Copy Chapter

These are two products sharing one dialect and one model. Most of what follows
is true of both. Where they differ, the model gates on the product rather than
on the release number, because MariaDB is at 11.8 and MySQL at 9 and neither
number says anything about the other. See D44.

MariaDB answers 30 of the 65 and MySQL answers 27. The three MySQL cannot
answer are sequences, which it has never had, aggregates, which it has no form
of and whose catalog table it dropped in 8.0, and column statistics, below.

What it answers with the same thing PostgreSQL has Copy Section

Schemas, databases, tables, columns, indexes, index columns, constraints,
constraint columns, triggers, sequences, views, partitioned tables, comments,
functions, routine parameters, collations, settings, roles, role grants,
privileges, column statistics, the current schema and the current user.

A schema and a database are the same object in MariaDB. dbmeta.Schemas and
dbmeta.Databases both answer, and they answer with the same rows. That is the
one place the object model does not fit, and it is not hidden.

The fields that D205 fills Copy Section

D198, D199 and D203 added fields and kinds that only PostgreSQL filled. D205
reads each of them from the catalog of the MySQL family and leaves NULL where
the catalog has no source. Every field below is a column of a row that the
statement already reads, so the cost is the cost of the row.

Gemini and DeepSeek were asked on 2026-10-10, as rule 14 requires. Both named
mysql.innodb_index_stats for the index size, and the INNODB_INDEXES view
(INNODB_SYS_INDEXES on MariaDB) for the clustered flag, and said that no
view holds a compression method of a column or an owner of a table. DeepSeek
said that MariaDB writes the column compression into COLUMN_TYPE, and the
run confirmed it. I ran both leads as a user with SELECT on one schema, and
both views answered Access denied; you need the PROCESS privilege, so the
two fields stay NULL. TABLE_ROWS, DATA_LENGTH and INDEX_LENGTH of a
view are NULL on MariaDB and MySQL, and Table.Size and Rows keep that.
ENFORCED is not a column of TABLE_CONSTRAINTS on MariaDB 10.6 to 13.0, and D212 fills it with true.

What it answers with an analogue Copy Section

Four of these need SELECT on the mysql schema, because mysql.proc,
mysql.func and mysql.servers are tables rather than views and MariaDB does
not grant them to an ordinary user. PostgreSQL makes the same information
readable by everyone. A caller without that privilege gets an error from the
driver, not from dbmeta.

ForeignTables reports the engine in the server column, because
information_schema does not publish the CONNECTION setting that names the
server. The field says so.

Where the two products differ Copy Section

Functions reads routine_body for the language and never
external_language. MariaDB leaves external_language NULL for a SQL routine
and MySQL writes SQL, and the field is not nullable, so reading it fails to
scan on MariaDB. The cross product test found that.

What the two products answer the same way, and what they spell differently Copy Section

TestMySQLAgainstMariaDB builds the same fixture on one server of each product
and compares every query that narrows to one schema. Fourteen queries compare,
measured on 2026-10-01, and every column agrees except the ones below.

Columns.DataType and Columns.Default. MariaDB keeps the display width of an
integer and MySQL dropped it, so a column reads int(11) on one and int on
the other. MariaDB quotes a string default and MySQL does not, so the same
default reads 'red' and red.

Columns.Collation. Each product has its own default collation, and a text
column that names none takes it: utf8mb4_uca1400_ai_ci on MariaDB from
11.4, and utf8mb4_0900_ai_ci on MySQL from 8.0. The compare job in CI
failed on it from the change that added the field until it was named.

Constraints.Definition. MariaDB records the check clause as written and MySQL
rewrites it with the character set introducer, so `title` <> '' becomes
(`title` <> _utf8mb4'').

RoutineParameters.DataType. The same display width difference, reaching a
parameter through dtd_identifier rather than a column.

Views.Definition. Neither product stores a view as written. Both rewrite it,
and they rewrite it differently: MySQL parenthesizes the WHERE clause and
MariaDB does not.

Those four are named in the test. Any other difference fails it, so a query
written for one product and run against the other is caught here rather than by
a user. It has caught three faults so far, the most recent in CI: the
comparison keyed a row by its name and ordinal without the routine it belongs
to, so two routines' return values, both reported with no name at ordinal zero,
looked like one row whose name kept changing.

COLLECTION_COUNT on 1500 collections took 10.6 to 12.0 ms against 1.9 to
2.1 ms for the list alone, and 0.85 ms for one collection by name (D212).

What it cannot answer, and why Copy Section

MariaDB has no equivalent of any of these. Reporting them unsupported is the
whole answer.

Analogues that were found and rejected Copy Section

Two AI models were asked what MariaDB holds for the 29 questions the first pass
did not answer, which is the rule D43 sets. Both named analogues that do not
survive a look at a running server. They are recorded here so that the next
person does not find them again and reach the other conclusion.

information_schema.TABLESPACES for Tablespaces. Both models named it. The
table exists and it has the right columns, and on MariaDB 11.8 it returns no
rows and can never return any: it is the MySQL Cluster table, kept for
compatibility. information_schema.INNODB_SYS_TABLESPACES does return rows,
and each row is one file behind one table, not a named place an administrator
created. A list that names dbmeta_fixture/book as a tablespace teaches a
caller something false.

information_schema.ENGINES for ForeignDataWrappers. An engine is already
the answer for AccessMethods, and an engine is not a wrapper: it is not named
by CREATE SERVER and a server does not point at one. mysql.servers.Wrapper
holds a real wrapper name, but only for wrappers already in use, and \dew
lists the wrappers a server has rather than the ones it uses.

mysql.column_stats, mysql.table_stats and mysql.index_stats for
ExtendedStats. These hold engine independent statistics, one row per column.
\dX lists the statistics objects CREATE STATISTICS makes, and the point of
those is that they cover several columns at once. A single column histogram is
a different thing with a similar name.

information_schema.PLUGINS with PLUGIN_TYPE of FTPARSER for
TextSearchParsers. A full text parser plugin genuinely is a text search
parser, so this one is close. It was rejected because the built in parser is
not a plugin and does not appear, so a default install answers with no rows
while full text search works. psql lists the built in parser for \dFp, and
an empty answer here reads as "this server has no full text search".

mysql.slave_master_info for Subscriptions. MariaDB does not have that
table. It keeps master information in a file, and SHOW SLAVE STATUS is the
way to read it, which is not a catalog query.

Catalogs MariaDB has that no question asks for Copy Section

These hold real metadata and no psql command maps onto them, so dbmeta does
not read them. A later question can.

information_schema.EVENTS holds scheduled events, which PostgreSQL has no
form of. information_schema.PERIODS holds application time periods. It is present on
11.8 and absent on 10.6, so a query for it needs a version gate.

SQLite Copy Chapter

SQLite answers 14 of the 65. It is a small native model and it still beats
the shared information_schema one, which SQLite does not have at all.

It is also one of the two databases here with no server, and DuckDB is the
other. SQLite is a library, so the
release under test is whichever one the Go driver was built with. There is
nothing to upgrade separately, nothing to run in a container, and no version
gate in the model: every pragma it reads arrived by SQLite 3.37 in 2021, and
the only way to reach an older one is to pin an old driver on purpose.

Two drivers are tested, as subtests named for each. mattn/go-sqlite3 compiles
the upstream SQLite source and needs cgo, which is why it is the primary one:
it is the real database. modernc.org/sqlite is a pure Go translation and is
what a consumer who cannot use cgo runs. They ship different library versions
in general, and they happen to agree today. See D48.

What it answers Copy Section

Eleven from psql and three of the six D47 added: the columns of a constraint,
the statement a view selects, and the schema an unqualified name resolves in.
It cannot answer routine parameters, enum values or column statistics, and the
reasons are in the table under The seven kinds psql has no command for.

A correlated table-valued join is what makes most of these one statement
rather than one per table:

FROM sqlite_schema m JOIN pragma_table_xinfo(m.name) c

The one query that answers incompletely Copy Section

Constraints reports primary key, unique and foreign key, and never reports a
check constraint. SQLite records a check constraint only inside the
CREATE TABLE text in sqlite_schema.sql, and dbmeta does not parse DDL.

This is the one place a query here answers partially rather than not at all.
Both Gemini and DeepSeek argued for it and they are right: three kinds read
exactly are worth more than refusing all four over the fourth. The field
description says so, and the test creates two check constraints and asserts
that neither appears, so the gap is tested rather than assumed.

Settings, which is assembled rather than written Copy Section

There is no way to ask SQLite for the value of a pragma it names.
pragma_pragma_list gives names and no values, and reading a value means
naming the pragma in the SQL. So the query is built at startup from a list of
36 pragmas, one SELECT each, joined by UNION ALL.

Two things that only running it reveals. A pragma appears in
pragma_pragma_list whether or not it can be read as a table, so
mmap_size, wal_autocheckpoint, wal_checkpoint, case_sensitive_like and
temp_store_directory are left out: they are pragmas and they are not tables.
And busy_timeout returns a column called timeout, which is the only one in
the list not named after its own pragma.

compile_options is left out on purpose. A build flag is not a setting a
caller can change, which is what \dconfig means.

Analogues that were found and rejected Copy Section

Two AI models were asked what SQLite holds for the 37 questions the first pass
did not answer, which is the rule D43 sets. They agreed on almost all of it,
and every rejection below is theirs as well as mine.

sqlite_sequence for Sequences. It exists only when a table uses
AUTOINCREMENT, and it gets a row only after the first insert. It is a counter
SQLite keeps for itself, not an object anyone created, and nothing can read the
next value from it.

pragma_module_list for Extensions, AccessMethods or
ForeignDataWrappers. A module implements a virtual table. It is not an
extension, it is not an index method, and nothing wraps foreign data with it.

A virtual table for ForeignTables, the way a FEDERATED engine answers for
MariaDB. This one looked right and it is not: a virtual table is also how
SQLite does full text search, JSON and R-trees, so most of what the query
returns is local data.

pragma_compile_options for Settings, rejected above.

sqlite_stat1 for ExtendedStats. It holds one row per index, which is
PostgreSQL's pg_statistic, not the CREATE STATISTICS objects that \dX
lists.

pragma_table_xinfo.type for Types. A declared type in SQLite is an
unenforced affinity hint. A column of them presented as a type catalog
suggests a check that does not happen.

pragma_function_list type a and w for Aggregates. This is the one the
models split on, and running it settled it against both. Gemini said to map
both and called it exact. DeepSeek said to map only a. On a real server,
sum, count, avg and group_concat all report as w, and so do
row_number, rank and lag. Type a matched one function, an extension.
If the query maps w, it lists row_number as an aggregate. If it maps a,
it omits sum. Both mislead, there is no third option, and SQLite cannot
tell an aggregate from a window function. Aggregates is unsupported and
Functions reports the kind SQLite reports.

What it has none of Copy Section

SQLite has no users, no roles and no grants of any kind, so Roles,
RoleGrants, RoleSettings, Privileges and DefaultACLs are absent rather
than empty. It records no comment on any object. It has no type catalog, no
operators that can be created, no casts, no procedural languages, no
replication, no tablespaces and no partitioning.

The describe fields (D208) Copy Section

D198 and D199 gave Tables, Indexes and Columns fields that only PostgreSQL
filled. D208 measured each one on SQLite 3.53.4, on both drivers.

A shadow table of an fts5 table is listed as a table. pragma_table_list
calls it shadow, and relabeling it is not done.

Cassandra Copy Chapter

Cassandra answers 17 of the 65, verified against 5.0.9 and 3.11.19.

It is the first database here that is not SQL, and CQL is narrower than the
name suggests. D62 holds the four consequences and this is the short version.

The image is built here Copy Section

The Apache image refuses three things this model has queries for, and its
entrypoint maps only eight cassandra.yaml keys to environment variables,
none of them these. So every release is rebuilt from
test/cmd/dbrun/image/cassandra.Containerfile, which dbrun embeds and builds when the image is missing, so
nothing has to be done first, and CI builds its own from the same file.

It turns on user defined functions, so Functions and Aggregates have
something to read and the fixture can create one. It turns on materialized
views, which 5.0 ships off and 3.11 ships on, so Views behaves the same on
every release. And it sets PasswordAuthenticator and CassandraAuthorizer,
without which system_auth holds one role and no grant, and D61 has no second
principal to compare against.

The key names changed and the build handles both. 3.11 and 4.0 write
enable_user_defined_functions and enable_materialized_views, and 4.1 and
later write user_defined_functions_enabled and materialized_views_enabled.
usql publishes an image that does the same thing, as
docker.io/usql/cassandra, and its Dockerfile edits only the older spelling,
so it has no effect on 5.0. The build here checks the result rather than
trusting sed, because a sed that matches nothing changes nothing and says so
to nobody.

The superuser is cassandra and so is its password. It is the one product
here that does not use the shared test password, because Cassandra creates
that pair and it is the only one that works until somebody changes it.

The setup also makes the ordinary user dbmeta_user on every release, with the
shared test password. It can log in, it is no superuser, and it holds no
permission. Every role reads system and system_schema, so it gets the same
answers as the administrator except for the tables that hold roles and
permissions. On Cassandra, Roles, RoleGrants and Privileges are refused
to it, and so is Settings from 4.0, which reads system_views. On ScyllaDB,
Privileges, RoleGrants, RoleSettings, Roles and Settings are refused.
test/testdata/parity.txt holds the answer under [cassandra/same/user] and
[scylla/same/user]. D195 has the reasoning.

What it answers Copy Section

Keyspaces as schemas, tables, columns, materialized views as views, user
defined types, indexes, index columns, the primary key as a constraint and its
columns, triggers, comments, functions, aggregates, roles, role grants,
privileges and settings.

Settings needs 4.0, where the system_views keyspace arrived. Everything
else answers on every release from 3.11 up. That is the only fragment gated on
a Cassandra release, which is why the tested pair spans it. The other
fragments gate on the scylla key.

No statement filters, and the Keep function of each binding does Copy Section

CQL has no OR, no IS NULL outside a materialized view definition, and a
partition key takes only = or IN. The form every other model uses,
(@schema IS NULL OR col LIKE @schema), cannot be written. There is no
NOT IN either, so the keyspaces Cassandra keeps for itself cannot be
excluded in a statement.

So every statement returns every row, and each binding sets Keep
(D200). Query.All calls it after Scan and does not yield a row that it
rejects. schema matches the keyspace, name matches the name of the
object, and parent matches the table that a column, an index, a constraint
or a trigger belongs to. The match is dbmeta.LikeFold, so % is any run of
characters, _ is one, and the case of letters does not matter, because an
unquoted CQL name is case insensitive (D202). types on Tables keeps table, which is the only type this query
returns. A role, a role grant, a role setting and a setting belong to no
keyspace, so a schema pattern other than empty or % matches nothing for
them.

with_system is false by default, as it is for every model. It hides the
keyspaces system, system_schema, system_auth, system_distributed and
system_traces, which Cassandra 3.11 and 5.0 list in system_schema.keyspaces.
ScyllaDB lists those and also system_replicated_keys, which both releases
have, system_distributed_everywhere, which 2025.1 has, and audit, which
2026.3 has. The model holds the list as data. The virtual keyspaces
system_views and system_virtual_schema are in the list too, but Cassandra
5.0 keeps them in system_virtual_schema.keyspaces, so no statement here
returns them. A privilege on a resource inside a system keyspace is hidden too.

The cost is that one statement reads every row of the catalog and the filter
runs in Go, so the work grows with the whole catalog and not with the rows
returned. D47 does not allow that for a model that can filter in SQL, and this
one cannot. The catalog of Cassandra is small. Measured on Cassandra 3.11 with
a scratch keyspace of 300 tables and 1200 columns beside the 36 tables and 234
columns of the system keyspaces: Tables read 336 rows in 3 ms and returned
300 of them, and Columns read 1434 rows in 9 ms without a filter and in 5 ms
with one, on a local container.

A derived field is derived in Go Copy Section

There is no CASE and no expression. Column.Nullable and
Column.PrimaryKey are both read from system_schema.columns.kind, which the
statement selects twice, and Scan turns each into its boolean. A column of
kind partition_key or clustering is in the primary key, and the primary key
is the only thing in Cassandra that cannot be null.

No order Copy Section

CQL orders rows within one partition and by a clustering column. A result that
spans partitions arrives in token order, so the same query can return the same
rows in another order on another cluster. No query writes ORDER BY, because
one does not make the answer ordered.

What the fixture builds, and what it needs Copy Section

models/cassandra/fixture creates the keyspace dbmeta_fixture with the core
objects D53 asks every fixture for, plus one of every Cassandra object the
queries read: a user defined type, a secondary index, a materialized view, a
function, an aggregate built on a second function, two roles, a grant between
them and a permission on the keyspace. Twenty one steps. Cassandra runs
nineteen on every release and skips the two service level steps, which run on
ScyllaDB alone.

It needs the image this repository builds. Against the published one the
function, the view and the roles are all refused, and the test says so rather
than quietly building less.

Three tables show three shapes of primary key, because that is the one
constraint Cassandra has and the queries report it: author has a partition
key alone, book has a partition key and a clustering column, and region
has a two column partition key.

No trigger. A Cassandra trigger names a Java class that has to be on the
server's classpath already, so the fixture creates none and Triggers returns
no rows anywhere. It is the one registered query with no fixture object.

A null arrives as a null Copy Section

The tests use github.com/xo/cassandra, which reports a CQL null as NULL. The
driver before it sent an empty string for every null, and D62 worked around
that by discarding each padded column. D93 records the change.

A real catalog column that is null now reaches the caller as NULL, so Valid
means what it means on every other dialect. Cassandra itself stores the empty
string rather than a null for a table with no comment, so an uncommented table
reports a valid empty comment. That is what the catalog holds.

What the conformance test says Copy Section

Cassandra is in test/testdata/conformance.txt under [cassandra], and it
agrees with the relational databases on less than they agree with each other.
That is why TestConformanceAgreementHolds now measures twice: the relational
databases against the floor they have always held, and every database against
a smaller one. If Cassandra counts with the rest, the floor drops from 23
lines to 6 and is too low to notice a regression anywhere.

Two differences and neither is a fault. There is no table recent view line,
because Tables returns no view: a materialized view is in
system_schema.views and CQL has no UNION to put the two together. And the
column ordinal is a position within the primary key rather than within the
table, because the catalog keeps no declaration order and holds a table's
columns alphabetically.

What Cassandra has none of Copy Section

No sequence, no domain, no enumerated type, no cast, no collation catalog, no
operator, no text search object, no extension, no foreign data wrapper, no
tablespace and no large object. No Databases either: a keyspace is the top
of the tree and the cluster above it is in system.local, which no single
statement can reach from system_schema because CQL has no join.

CurrentSchema and CurrentUser are absent and both models agreed. There is
no CQL expression for either. system_views.clients from 4.0 lists every
connection with the user on it and cannot say which one is asking, so it is
not the same fact.

RoutineParameters is the one that is present and not returned.
system_schema.functions holds argument_names and argument_types as two
parallel lists on the function's own row, and turning them into one row per
parameter needs an unnest that CQL does not have. The types are in
Functions.ArgTypes as one text.

ColumnStats is absent from the catalog. The statistics Cassandra keeps are
per SSTable and per node, in system_views from 4.0, which is a different
thing from the per column distribution psql prints.

PartitionedTables is a stretch and is left unsupported under the D43 rule.
Every Cassandra table is partitioned, so a list of the partitioned ones is a
list of all of them and says nothing.

The describe fields (D210) Copy Section

The table options, the class and the options of a custom index, and Prosrc of a function are filled. The ScyllaDB section below lists them.

ScyllaDB Copy Chapter

ScyllaDB answers 18 of the 65, verified against 2025.1.15, 2026.1, 2026.2 and
2026.3.1. It is a second product that speaks CQL, and models/cassandra reads
it. Cassandra is the reference product and ScyllaDB is the flavor, the way
MariaDB and MySQL share models/mysql. D91 is the decision.

How the model knows which product it has Copy Section

ScyllaDB puts a supported_features column in system.local, and Cassandra
has no such column. The version query reads the whole row as one JSON text,
with SELECT JSON *, because CQL refuses a statement that names a column the
table does not have. A row with that column is ScyllaDB, and the model records
the scylla version key.

Its release_version is 3.0.8 on every release measured. That is the
Cassandra release that ScyllaDB keeps compatible with, not its own release,
and it stays the main version, because it describes the catalog that ScyllaDB
offers. The ScyllaDB release is in system.versions, which Cassandra does not have,
so a second statement reads it, and only on ScyllaDB. D92 is the decision. A
role granted nothing is refused system.versions and served system.local,
so it learns that it is talking to ScyllaDB and not which release. The
version read does not fail for it.

What differs from Cassandra Copy Section

ScyllaDB keeps system_schema as Cassandra 3.0 laid it out, so most queries
need nothing. Four things differ, and each one is a fragment on the scylla
key:

1. Roles, role grants and permissions are in system.roles,
   system.role_members and system.role_permissions, with the columns that
   Cassandra has in system_auth. system_auth.roles is refused as an
   unconfigured table on both 2025.1 and 2026.3.
2. Settings are in system.config, which also records a type for each
   setting and where its value came from. The value arrives as JSON, so a text
   value is in double quotes. The system_views gate at Cassandra 4.0 does
   not reach ScyllaDB, because its main version is 3.0.8, so the ScyllaDB
   fragment is the one that answers.
3. No literal is allowed in a select list. 2025.1 refuses (text)NULL,
   (boolean)false and CAST(false AS boolean) as syntax errors. 2026.3
   takes the cast and still refuses every NULL. So where the Cassandra
   statement selects a literal, the ScyllaDB fragment selects a real column of
   the same table under the same name, and Scan discards that column on both
   products and sets the known value itself.
4. RoleSettings has a source. system.role_attributes holds a value set on
   a role, and ATTACH SERVICE LEVEL is what sets one. It gives the role's
   sessions the timeout and the share of the server that the service level
   names, which is the ScyllaDB form of ALTER ROLE ... SET. The row is per
   attribute, because CQL cannot group.

A secondary index is also a view Copy Section

ScyllaDB builds a secondary index as a materialized view. Views returns the
view that backs the fixture's index, book_author_index, beside the view the
fixture creates, so it reports two rows where Cassandra reports one. The
catalog holds the row, and hard rule 13 says to return it. A consumer can tell
the two apart with Indexes, which names the index.

The container needs its settings as arguments Copy Section

The published image docker.io/scylladb/scylla passes every argument that its
entrypoint does not know to scylla itself, so nothing is built. The
arguments turn on PasswordAuthenticator, CassandraAuthorizer and user
defined functions, and hold the server to one shard and one gigabyte.

2026.3 does not create the cassandra role that Cassandra creates. So the
superuser is named at startup with --auth-superuser-name and a salted
password, which 2025.1 also takes. The pair is cassandra and cassandra,
the same as the reference product, so one set of test helpers logs in to both.
The entrypoint writes the arguments into a file that a shell reads, so each
dollar sign in the salted password is escaped once.

What the fixture does differently Copy Section

Three steps have a ScyllaDB form, and two steps run on ScyllaDB alone:

1. The keyspace uses NetworkTopologyStrategy and turns tablets off.
   ScyllaDB refuses SimpleStrategy, because it places a new keyspace on
   tablets, and 2025.1 refuses a secondary index and a materialized view on a
   keyspace that uses tablets.
2. The two functions are written in Lua. ScyllaDB runs no Java, and it takes
   Lua and WebAssembly behind an experimental flag.
3. A service level is created and attached to dbmeta_reader, so that
   RoleSettings has a row. The teardown drops it last.

Twenty one steps run on ScyllaDB and none is skipped. Cassandra runs nineteen
and skips the two service level steps.

What a second opinion found Copy Section

Gemini and DeepSeek were both asked to sort the 38 unanswered kinds. Both
called 35 of them absent and named three leads. None of the three is a
source:

RoleSettings from system.role_attributes was found here rather than
offered, while reading the tables that the system keyspace holds.

What the conformance test says Copy Section

ScyllaDB gives the canonical answer that Cassandra gives, line for line, under
[cassandra] in test/testdata/conformance.txt. The flavor agrees with the
reference product on everything the projection reads.

Which answers depend on who is asking Copy Section

A role granted every permission on the fixture keyspace is refused the same
four queries as on Cassandra, from the system tables rather than from
system_auth and system_views, and is refused RoleSettings as well. All
four releases give the same answer, under [scylla/same/grantee] in
test/testdata/parity.txt.

The describe fields (D210) Copy Section

Tables reads the table options from compaction, compression, gc_grace_seconds and default_time_to_live of the same row, as compaction=..., compression=..., gc_grace_seconds=..., default_time_to_live=.... Indexes reads the class and the other options of a custom index, which the storage attached index of Cassandra 5.0 has. Functions reads body as Prosrc. The size and the rows are NULL, because CQL has no join to system_views.disk_usage or system.size_estimates. The owner, the persistence and the column fields have no source. ScyllaDB fills the same fields, and has no custom index.

ClickHouse Copy Chapter

ClickHouse answers 25 of the 65, verified against 26.9.2.8 and 25.8.33.6.

system, not information_schema Copy Section

ClickHouse ships both. information_schema is an emulation that reports what
the standard names and drops everything that makes a ClickHouse table what it
is: the engine, the partition key, the sorting key, the compression codec per
column, and the data skipping indices. Every query here reads system, which
is about 150 tables and the richest native catalog in this project after
PostgreSQL's.

A database is a schema Copy Section

ClickHouse has one level of namespace and calls it a database, so Schemas
and Databases read the same table under both names. models/mysql does the
same thing with information_schema.SCHEMATA for the same reason.

What it answers Copy Section

Schemas and databases, tables, columns, views, indexes, index columns,
constraints, comments, partitioned tables, types, collations, settings, roles,
role grants, privileges, functions, aggregates, tablespaces, foreign servers,
foreign tables, the current schema and the current user.

Two of those are an analogue rather than the same object, and both reviews
agreed they are real rather than a stretch. A storage policy names the volumes
and disks a table's parts live on, which is what a tablespace is for. A table
whose engine is MySQL, PostgreSQL, S3 or one of the others reads rows another
system holds, which is what a foreign table is, and a named collection is the
stored connection it uses.

Two columns arrived in the same release Copy Section

system.constraints and system.functions.deterministic are both absent on
25.3, 25.8 and 26.1, and both present on 26.8 and 26.9. They gate at 26.8,
which is the release they were first seen in rather than the release they
arrived in: somewhere in 26.2 to 26.8 is as precise as a check against running
servers can be, and gating late under reports rather than breaking.

Constraints is the whole query, so an older server is told it is too old.
Volatility is one column of Functions, so an older server gets it padded and
Field.Min says which is which.

What Cassandra taught us to check here too Copy Section

The conformance projection contributes no constraint lines for ClickHouse.
There is no primary key constraint, no foreign key and no unique constraint,
and system.constraints holds the expression a CHECK asserts rather than the
columns behind it, so the model registers Constraints and not
ConstraintColumns. If ClickHouse counts in the cross family agreement
number, the number drops from 23 lines to 14. So ClickHouse is measured
separately for a stated reason, the way Cassandra is.

What the fixture cannot build Copy Section

A named collection. Creating one needs
access_control_improvements.named_collection_control in the server
configuration, and the official image exposes no variable for it. The
ForeignServers query is verified to run and returns no rows, which is the
same position Cassandra's triggers are in.

Everything else the fixture builds, including a user, a role and a grant,
which need CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT and container/clickhouse.go
sets it.

What ClickHouse has none of Copy Section

No sequence, no domain, no trigger, no operator catalog, no extension, no
large object, no text search object of the shape psql names, and no user
defined type: Enum, Array and Tuple are spelled inside a column's type rather
than declared.

To answer EnumValues, a query must parse the enum out of a type string,
which is not a catalog read. RoutineParameters is absent because a ClickHouse function is
overloaded across types and system.functions records no signature.
ColumnStats is absent: system.columns carries compressed and uncompressed
sizes and nothing about distribution, and what system.parts holds is per
part rather than per column.

The describe fields (D208) Copy Section

Gemini agreed that ClickHouse has no owner, no statistics target and no flag for
row security. DeepSeek ran out of tokens on every question.

Trino Copy Chapter

Trino is a query engine rather than a store. It reads other people's data
through a connector and keeps almost nothing of its own, so most of what it
cannot answer is missing because the thing does not exist rather than because
the catalog hides it.

A catalog is a real level, and only Trino and Presto have one Copy Section

Every other model here returns an empty catalog or repeats the database name
into it, because the products have two levels of namespace and psql has
three. Trino has all three. A table is catalog.schema.name, a catalog is a
configured connector, and one server reaches many at once.

So Trino and Presto are the only models that answer a catalog filter, and
dbmeta.Args has carried the field all along waiting for them.

system.jdbc, not information_schema Copy Section

Trino ships an information_schema inside every catalog and a system
catalog beside them, and the two differ in reach. A query against
memory.information_schema.tables sees the memory catalog and nothing else,
and the catalog cannot come from a bind parameter, so a filter that names a second
catalog returns nothing rather than an answer. That is a wrong answer
rather than an empty one, which rule 13 does not allow. The tables under
system.jdbc span every catalog the server has.

system.jdbc is also the richer of the two. Its columns table carries the
column comment in remarks, and information_schema.columns has no column
for a comment at all.

What it answers Copy Section

13 of the 65. Catalogs as databases, schemas, tables, columns, views,
comments, types, access methods, roles, role grants, privileges, the current
schema and the current user.

A connector is the analogue for an access method, the same way a storage
engine is for MariaDB: both answer "how is this stored and reached". The
comment on a connector is the list of catalogs it backs, because one
connector can back several.

The one query that cannot span catalogs Copy Section

Views. No cross catalog source carries a view definition:
system.metadata.materialized_views has one and covers materialized views
only, and a plain view's definition lives in the information_schema.views of
its own catalog. A read of every catalog takes one statement per catalog,
which rule 13 forbids.

So Views reads the session catalog, and its schema parameter says so where a
caller reads it. Every other query here spans catalogs.

A boolean is not an integer Copy Section

Every other model writes @with_system = 1 and the server coerces. Trino
applies no implicit conversion between a boolean and an integer and refuses
the statement with Cannot apply operator: boolean = integer, so this model
writes = true. Seven queries were written the other way first and all seven
failed at once, which is the cheapest way for that to be found.

What the fixture cannot build Copy Section

No primary key, no foreign key, no unique constraint and no check. Trino has
no constraint of any kind at any release, so nothing enforces that a book has
an author. No sequence, no trigger, no index and no user defined type. No
default: Trino parses DEFAULT and the memory connector keeps none.

No role and no grant either, and that one is the connector rather than the
engine. A Trino role belongs to a catalog, only a connector that implements
role management has any, and the memory connector answers "does not support
role management" to CREATE ROLE. Roles, RoleGrants and Privileges are
verified to run and return no rows, and TestTrinoRolesAreEmptyOnMemory pins
that so it stays distinguishable from a broken query. A connector with
sql-standard security, such as Hive, populates all three.

No materialized view: the memory connector refuses to create one.

What the conformance test says Copy Section

Trino builds every core object D53 asks for, including the view, and the
column ordinals and nullability match every other database. It is left out of
the relational agreement count for the same reason ClickHouse is: with no
constraint catalog every column reads primary_key=false where the others
agree on the key, and there are no constraint lines to compare.

What a second opinion found, and what it cost to check Copy Section

D43 requires asking at least two models about the queries a new dialect cannot
answer. Gemini and DeepSeek were both asked to sort 42 unanswered kinds into
absent, present under another name, and derivable from one statement.

Every lead was run against a real server, which is the part of the rule that
matters. DeepSeek named eight sources that do not exist:

system.metadata.functions             ABSENT
system.metadata.partitions            ABSENT
system.metadata.types                 ABSENT
system.metadata.column_comments       ABSENT
system.metadata.session_properties    ABSENT
information_schema.parameters         ABSENT
information_schema.table_constraints  ABSENT
information_schema.key_column_usage   ABSENT

Three of its answers rested on system.metadata.functions alone: functions,
aggregates and operators. SHOW CASTS is not a statement Trino has, and no
table reports table_type = 'FOREIGN'. Gemini named nothing that does not
exist, and put all but six kinds in absent.

Two answers were worth the exercise.

Functions cannot be read as a relation, and now that is settled. Gemini
said SHOW FUNCTIONS cannot be wrapped in a subquery and it is right, though
not for the reason it gave. The parser does not reject it: it reads SHOW as
a table name and reports Table 'memory.default.show' does not exist. So
there is no table valued source for the function list, the column names carry
spaces, and Functions and Aggregates stay unanswered. SHOW SESSION has the
same shape, which is why Settings is unanswered too, and both models agreed
SHOW STATS FOR has no table valued form, so ColumnStats is as well.

information_schema.columns has an undocumented column. Gemini derived
partitioned tables from extra_info = 'partition key'. SHOW COLUMNS does
not list extra_info and the column resolves anyway, which a control
settled: a name that really does not exist fails with Column 'definitely_not_a_column' cannot be resolved, and extra_info returns 0 non
null values over 34 rows. It is real, and the memory connector never sets it.
A connector that partitions, such as Hive, does.

PartitionedTables is left unanswered on that basis rather than on absence. The
source exists and no connector in the test image populates it, so rule 9 has
no object to build and nothing to verify the query against.

Which answers depend on who is asking Copy Section

None of them, and that is the measurement rather than a gap in it. Trino has
no users to create: a client states a principal on every request and the
server takes it, because the image configures no authenticator. With no access
control plugin the server then allows that principal everything, so the only
query that answers differently for a second principal is current_user, which
is the one that is supposed to.

The describe fields (D210) Copy Section

None are filled. system.metadata.tables_authorization is empty for the memory connector, SHOW STATS is one statement for each table, and the memory connector has no $partitions table.

Firebird Copy Chapter

models/firebird answers 25 of the 65, against Firebird 3.0.14, 4.0.7 and
5.0.4.

It reads RDB$, and there is no information_schema Copy Section

Firebird has no information_schema at any release in range. Its catalog is
the RDB$ tables, which are ordinary tables inside the database that a
statement reads the way it reads any other. Two other prefixes matter. MON$
is the monitoring set, and MON$DATABASE is where the attached database
describes itself. SEC$ is a view on the server's security database, and it
is where users live, because a user belongs to the server and a role belongs
to the database.

Two properties of RDB$ shape every query here, and both cost a round of
wrong answers before they were understood.

Every name is CHAR(63) and blank padded. Equality pads and LIKE does not,
so RDB$RELATION_NAME LIKE 'AUTHOR' matches nothing at all: the stored value
is AUTHOR followed by 57 spaces. A filter written without a trim looks correct
and returns an empty result rather than an error. Only the trailing blanks are
padding, so the model trims those alone and not a leading space, which a
quoted identifier is allowed to have.

Every bind parameter needs a cast. Firebird takes the type of a bare parameter
from what it is compared with, so ? = '' types it VARCHAR(0) and the server
then refuses any value:

arithmetic exception, numeric overflow, or string truncation
string right truncation
expected length 0, actual 6

An empty filter still passes, which is what makes it worth writing down. A
first run with no arguments reports nothing wrong.

There are no schemas, and none is invented Copy Section

Firebird 3.0 through 5.0 has no schemas. Every object lives in one namespace
and names are unique across the database. Firebird 6.0 adds SQL schemas and is
out of range.

So Schemas and CurrentSchema report NotSupported, and every other query
returns an empty schema. A caller that cannot see the server is not able to
tell an invented name from a real one, and an empty result must never
stand in for NotSupported, which is D34. TestFirebirdSchemasAreNotSupported
holds both halves of that.

A Firebird database is a file rather than a name, and the server keeps no
catalog of the files it has served, so Databases returns exactly one row: the
database attached, named by its path.

What it answers Copy Section

Tables, columns, views, indexes, index columns, constraints, constraint
columns, triggers, event triggers, sequences, domains, functions, routine
parameters, types, collations, roles, role grants, privileges, comments,
databases, settings, publications, publication tables and the current user.

Three of those need 4.0 and report TooOld on 3.0, which D63 added the state
for: Settings reads RDB$CONFIG, and Publications and PublicationTables
read RDB$PUBLICATIONS and RDB$PUBLICATION_TABLES. None of the three exists
before 4.0.

Two answers take a second source and are worth naming.

A check constraint has no index, so it has no entry in RDB$INDEX_SEGMENTS
and the join every other constraint uses cannot reach its columns. Firebird
implements a check with a pair of system triggers and records the columns as
those triggers' rows in RDB$DEPENDENCIES, and nowhere else. That is the
second arm of ConstraintColumns, and TestFirebirdCheckConstraintColumns
exists so that it cannot quietly stop working: without it the result is
a shorter list.

A foreign key names the unique constraint it references rather than the table,
so reaching the target column takes three more joins: to RDB$REF_CONSTRAINTS
for the referenced constraint, to its row in RDB$RELATION_CONSTRAINTS for the
table, and to that constraint's index segments for the column in the matching
position.

Roles is one statement over two places, because Firebird splits what
PostgreSQL keeps in one. SEC$USERS holds the users and RDB$ROLES holds the
roles, and can_login is what tells them apart.

A member of a package is left out of Functions, the way models/oracle
leaves one out. It is not callable by name on its own, and the package is what
a caller names.

What it cannot answer, and why Copy Section

Thirty-two kinds have no answer and every one of them is absent from the
product rather than hidden by the catalog.

There are no schemas, no tablespaces, no user defined casts, no operators, no
user defined aggregates, no enumerated types, no extensions, no foreign tables
or foreign data wrappers, no text search objects, no operator classes or
families, no partitioned tables, no extended statistics, no default privileges
and no per role settings. Firebird has one index kind and no pluggable access
method, so there is nothing for AccessMethods to list.

Three deserve a reason rather than a word.

LargeObjects has no answer because a Firebird BLOB is addressed from the row
that holds it and page chain that follows it. There is no catalog of them to
list, so this is absence rather than reach.

ColumnStats has no answer either, and the near miss is worth recording.
RDB$INDEX_SEGMENTS.RDB$STATISTICS holds a selectivity, but it is an index
prefix selectivity rather than a per column statistic, and it is none of the
things ColumnStat carries: no average width, no null fraction, no distinct
count, no most common values. A report of it gives a different number under
the same name.

Languages is the one analogue left unsupported as a stretch, which rule 14
asks for explicitly. RDB$FUNCTIONS.RDB$ENGINE_NAME and the same column on
RDB$PROCEDURES name the external engine a routine is written for, so the
engines actually in use are derivable in one statement. That is a list of
languages in use and not a catalog of languages installed, and Firebird has no
catalog of the second. That list misses an unused engine, and a caller cannot
tell. The fact is not lost: Function.Language carries it per routine, which
is where Firebird records it.

Subscriptions is absent for a reason that is not obvious from the name.
Firebird 4.0 has logical replication and the publisher side is in the catalog,
which is why Publications answers. The subscriber side is configured in
replication.conf on disk and never reaches the database, so there is nothing
to read.

Firebird 5.0 added a partial index, whose predicate is in
RDB$INDICES.RDB$CONDITION_SOURCE. dbmeta.Index has no field to carry a
predicate, so the model does not read it and nothing here gates on 5.0. Adding
the field is a D47 question for every model rather than for this one.

What a second opinion found Copy Section

D43 and hard rule 14 require asking at least two models about the kinds a
first pass cannot answer, and this is the second time the rule has paid by
catching an invention rather than by finding a source. Trino was the first.

Gemini was asked about twelve concepts and answered absent for all twelve, and
every one of those answers was right. It also correctly identified
RDB$INDEX_SEGMENTS.RDB$STATISTICS as an index prefix selectivity rather than
a column statistic.

DeepSeek named seven sources. Six of them do not exist on a real Firebird 5.0
server and the seventh exists and is never filled:

Each was run rather than read, which is the whole of the rule. A lead is a lead
and nothing more.

What the fixture cannot build Copy Section

Nothing. The Firebird fixture builds all six core objects D53 asks for and all
33 of its steps run on 3.0, 4.0 and 5.0, except the one publication step, which
carries a gate and is skipped on 3.0 for the same reason Publications reports
TooOld there.

It creates no user, and that is deliberate rather than a gap. A Firebird user
lives in the server's security database, which every database on that server
shares, so a user that a fixture creates changes a database the test never
opened. test/parity_test.go creates its principal and removes it again,
because a parity test has to.

What the conformance test says Copy Section

Firebird's section of test/testdata/conformance.txt is identical to
PostgreSQL's except for three lines, and on all three Firebird agrees with the
other eight databases rather than differing from them. PostgreSQL reports
has_default=true on author_id, book_id and shipment_id because its
fixture declares them serial. Firebird's keys are plain integers, the way
they are everywhere else.

Everything else matches exactly: the tables and the view, every column with its
ordinal, nullability and primary key flag, the composite primary key on
region, the composite foreign key from shipment into it with both target
columns, the unique constraint and the check.

Two faults in the driver, and where they do and do not matter Copy Section

Neither affects a consumer, and both cost enough to find that they are written
down here.

nakagami/firebirdsql returns a stale error for user management. After one
such statement fails, every later one on the same connection reports the first
error, while an ordinary query on that connection still works:

DROP USER dbmeta_absent  -> record not found for user: DBMETA_ABSENT
CREATE USER dbmeta_p1    -> record not found for user: DBMETA_ABSENT
SELECT COUNT(*) ...      -> <nil>
CREATE USER dbmeta_p2    -> record not found for user: DBMETA_ABSENT

Worse, a successful CREATE USER poisons a later read of SEC$USERS on the
same connection. The server answers EOF and drops the attachment, and the
pool's next connection then fails its handshake, so every query after that
reports a protocol error. It takes a few statements in between to become
reliable, which is why it looked intermittent until it was pinned down:

CREATE USER ...          -> <nil>
... ten metadata queries -> <nil>
SELECT FROM SEC$USERS    -> EOF

dbmeta issues no user management statement at any time and never will, so
neither fault can reach a consumer and Roles keeps SEC$USERS. The parity
test creates a principal, so it runs every such statement on a connection of
its own and closes it. That was measured against Firebird 5.0.4 with
nakagami/firebirdsql v0.9.21.

The describe fields (D209) Copy Section

D198 to D203 gave the root types fields that only PostgreSQL filled. D209 filled
what Firebird has a source for, on 3.0, 4.0 and 5.0. Every statement still
returns the same columns on every release.

SAP HANA Copy Chapter

models/hana answers 33 of the 65, against SAP HANA 2.00.088, which is
Tested, and 2.00.076 and 2.00.082, which run nightly. It ties SQL Server for
the richest answer after PostgreSQL and CockroachDB, which shares the
PostgreSQL model.

It reads SYS, and there is a lot of it Copy Section

SAP HANA has no information_schema. Its catalog is the SYS schema, a large
set of views that a statement reads like any other. That is why this model
answers as much as it does: a concept PostgreSQL has usually has a view here,
rather than an analogue that has to be argued for.

Three prefixes appear. A plain name such as SYS.TABLES is the catalog. A
name beginning M_ is a monitoring view and reports what the server is doing
now rather than what is defined. A name beginning _SYS_ is a schema the
server owns and not a view, which is why the system filter tests a prefix with
LEFT rather than with LIKE: an underscore is a single character wildcard
in LIKE, so LIKE '_SYS%' also matches ASYS and anything else of that
shape.

Two things about writing SQL for it, both measured rather than read.

A flag is the string TRUE or FALSE, and HANA refuses a bare comparison in a
select list. SELECT IS_PRIMARY_KEY = 'TRUE' FROM SYS.CONSTRAINTS is a syntax
error rather than a boolean, and so is comparing a CASE to FALSE, so the model
has both a yes and a no helper and writes the inversion out.

A bind parameter needs no cast, which is the opposite of Firebird. HANA infers
the type from the comparison, including where the same parameter appears twice.

The catalog keeps changing for about a minute after the server first answers.
Measured on 2.00.088 on 2026-09-30, the statistics service made more than 100
views in _SYS_STATISTICS in that minute, recorded its installation as done
in _SYS_STATISTICS.STATISTICS_PROPERTIES, and made the views of
_SYS_TELEMETRY about 12 seconds later. Nothing changed after that. A tier run
once read the tables while this happened and counted 896 views and then 895,
so checkTypes in test/scan_test.go reads again once when two counts
disagree, and fails only when the disagreement stays.

What it answers Copy Section

Tables, schemas, columns, views, indexes, index columns, constraints,
constraint columns, triggers, sequences, partitioned tables, functions,
routine parameters, types, collations, roles, role grants, privileges,
comments, databases, settings, access methods, column statistics, extended
statistics, foreign data wrappers, foreign servers, user mappings, foreign
tables, subscriptions, text search configurations, the current schema and the
current user.

Four of those are the reason HANA is worth having. Smart data access is real
foreign data with a view per concept, so all four answer from a catalog rather
than by analogy:

Only Exasol, CockroachDB and PostgreSQL answer all four as well.
SYS.REMOTE_SUBSCRIPTIONS answers
Subscriptions as well, which is the subscriber half of replication.

Three more are worth naming. SYS.DATA_STATISTICS answers extended
statistics, SYS.PARTITIONED_TABLES answers partitioned tables, and
SYS.TEXT_CONFIGURATIONS answers text search configurations, which is the one
member of that family HANA has.

Two answers needed a decision rather than a view.

AccessMethods reports the row store and the column store. A HANA table is
held one way or the other and the choice is per table, which is the same
question a MySQL storage engine and a Trino connector answer. HANA keeps no
catalog of the kinds, so the query counts the tables that name each one, and
a kind nothing uses does not appear. Tables carries the same fact per table,
so the type is row table or column table rather than table.

Constraints derives the kind from two flags and the check text, because
SYS.CONSTRAINTS has no type column: a primary key sets both flags, a unique
key sets one, and a check sets neither and carries the condition. A foreign
key is not in that view at all and comes from
SYS.REFERENTIAL_CONSTRAINTS, which is the one place in this project where
the referenced column is on the row itself rather than reached through the
referenced constraint.

What it cannot answer Copy Section

24 kinds, and every one because HANA has no such object.

There is no CREATE DOMAIN, no enumerated type, no user defined cast,
operator or aggregate, no tablespace, no DDL or event trigger, no publication,
no default privilege and no per role setting. There is no catalog of
procedural languages either: PROCEDURE_TYPE and FUNCTION_TYPE say what one
routine is written in, which Function.Language carries, and there is no list
of the languages installed. That is the same stretch Firebird's engine names
are, and it is left unsupported for the same reason.

Two are worth a sentence rather than a word.

LargeObjects has no answer because a HANA LOB is addressed from the row that
holds it. There is no catalog of them.

Publications has no answer although Subscriptions does, and that is not an
oversight. HANA replicates by subscribing to a remote source, so the
subscriber half is in the catalog and there is no publisher object at all.

What a second opinion found Copy Section

Gemini was asked about twelve concepts. It answered absent for eleven and
named SYS.REMOTE_SUBSCRIPTIONS for the twelfth, which exists and is the
source Subscriptions now reads. That is the first time in three dialects
that a second opinion found a source rather than only confirming an absence.

DeepSeek named three and two do not exist:

That is the third dialect running where DeepSeek invented a source and running
it was the only way to tell. See D43.

What the fixture cannot build Copy Section

Four things, and each is verified to run and return nothing rather than left
untested.

No remote source, virtual table or remote subscription: federating needs a
second database to federate to.

No text configuration: it is a repository object created outside SQL.

No data statistics object: CREATE STATISTICS needs rows, and the fixture
inserts none.

No column level grant, and this one is a product fact rather than a fixture
limit. SYS.GRANTED_PRIVILEGES carries a COLUMN_NAME column and HANA 2.0
SPS 08 has no GRANT syntax that fills it. Every spelling is a syntax error:

GRANT UPDATE(rating) ON t TO r        -> syntax error near "("
GRANT SELECT (rating) ON t TO r       -> syntax error near "("
GRANT UPDATE ON t(rating) TO r        -> syntax error near "("

So Privilege.ColumnAccess is always empty. The query keeps the column
because the catalog has it, and TestHANAHasNoColumnGrant asserts both halves
so that the absence stays a decision.

No user either. A HANA user belongs to the tenant database and outlives the
schema, so test/parity_test.go creates its principal and drops it again.

What the conformance test says Copy Section

HANA's section differs from PostgreSQL's in three places and each one is a
real difference rather than a gap.

The three has_default=true lines are PostgreSQL's serial keys, where HANA
agrees with the other nine databases.

A view's columns are reported NOT NULL where PostgreSQL reports them nullable.
HANA computes a view column's nullability from the column behind it, and
book_id and title are both NOT NULL, so the view says so. PostgreSQL
reports a view column nullable whatever is behind it.

There is no constraint book check (title) line, and the reason is
structural. A HANA check belongs to the table rather than to a column:
SYS.CONSTRAINTS leaves COLUMN_NAME and POSITION NULL on a check row, so
ConstraintColumns has nothing to report and the conformance line is built
from that query. The check itself is in Constraints with its condition, and
TestHANAConstraints reads it. Firebird reaches a check's columns through the
dependencies of the triggers that implement it, and HANA implements a check
without a trigger, so there is no equivalent to follow.

Which answers depend on who is asking Copy Section

Ten queries answer differently for a user that is not the administrator,
which is the most of any product here. That is HANA rather than the model:
almost every SYS view filters itself by what the reader is allowed to see, so a grantee
sees fewer collations, fewer databases, fewer adapters and fewer settings, as
well as fewer roles and grants.

Three of the ten return the same number of rows with different values:
functions, triggers and views. Those carry a definition, and HANA returns the
row and withholds the text from a reader without the privilege. That is worth
knowing before a consumer treats a definition as always present.

Sequences were recorded as a fourth until 2026-09-29, and that was wrong. The
catalog keeps a sequence's numbers as DECIMAL, and the driver hands a DECIMAL
over as a value that holds a pointer, so its text differed on every read.
The query casts the numbers to BIGINT now, and both principals read the same
rows.

The describe fields (D209) Copy Section

D198 to D203 gave the root types fields that only PostgreSQL filled. D209 filled
what HANA has a source for, on 2.00.088 as the administrator, and for a user
with one grant and a user with none.

Apache Hive Copy Chapter

models/hive answers 18 of the 65, against Apache Hive 4.2.1, which is
Tested, and 4.0.1, which runs nightly. It is the
only model here that writes its filter values into the statement, and the
reason is in D78 rather than here.

It reads sys, and Hive is not Impala Copy Section

Hive keeps its metadata in a relational metastore that SQL cannot reach.
Hive 3.0 added a sys database that exposes that metastore as external
tables over the JDBC storage handler, and those answer ordinary SQL. There
are 57 of them and they are what this model reads.

That is the difference D66 left open. D67 struck Impala because it answers
only through SHOW and DESCRIBE, which are statements rather than
relations and cannot be filtered, joined or aliased. sys is relations, so
Hive passes the test Impala failed.

sys is not there when a server starts. The script that creates it ships in
the image and needs a running HiveServer2 to run against, because the tables
are external tables pointed at the metastore. That is neither an image layer
nor a fixture, so container.Server.Init was added for it: a command run
once the server answers and before anything reads it. Hive is the only
product that sets it.

What it answers Copy Section

Tables, schemas, columns, views, constraints, constraint columns,
partitioned tables, functions, roles, role grants, privileges, comments,
column statistics, access methods, the current schema and the current user.

Three answers are worth naming because Hive arranges the fact differently
from everything else here.

Nullability, a default and a primary key are not properties of a column in
Hive. They are constraints in KEY_CONSTRAINTS, so Columns reads them
with three outer joins rather than from the column row. They are joins
rather than correlated subqueries because Hive does not take a correlated
scalar subquery in a select list.

A partition key is not a column of the table. It is in PARTITION_KEYS and
it does not appear in COLUMNS_V2 at all, so Columns does not report it
and PartitionedTables does.
TestHivePartitionColumnIsNotAColumn asserts both halves, because a caller
that reads only Columns sees a table without its partition column and that
absence otherwise looks like a bug.

A SerDe is how Hive reads and writes a table's rows, which is the question
an access method answers, so AccessMethods reports the SerDe classes in
use. Hive keeps no catalog of them, so the query counts the tables that name
each one and a SerDe nothing uses does not appear.

The trap in KEY_CONSTRAINTS, which cost a round of wrong answers Copy Section

Hive stores the two sides of a constraint the other way round from how the
names read, and only a foreign key has both. Measured on 4.2.1, with tables
115 and 116:

kp_pk  type=0  child(tbl=0)    parent(tbl=115)
kp_fk  type=1  child(tbl=116)  parent(tbl=115)

For a foreign key the child is the table that has the constraint and the
parent is the table it points at. For every other kind the parent is the
table that has it, and the child columns are zero rather than null.

Reading child as "the table this is on" is the obvious mistake and it was
made here first. It is worse than wrong: joining on a zero finds nothing
rather than dropping the row, so every primary key, unique, not null and
default goes silently missing while foreign keys keep working. A schema with
foreign keys in it looks correct. The model normalizes the two sides in a
derived table and the comment on it records the measurement.

What it cannot answer Copy Section

40 kinds, and almost all of them because Hive has no such object.

Indexes were removed in Hive 3.0 and there is no statement that makes one,
so Indexes and IndexColumns have no answer. There are no sequences, no
triggers, no domains, no collations, no user defined types, no operators and
no foreign data of any kind.

RoutineParameters has no answer for a reason worth stating: a Hive
function is a Java class registered under a name, and the metastore holds
the name and the class and nothing else. The parameters are in the class.
Function.Source carries the class name, which is the nearest thing to a
body Hive has.

Settings has no answer because Hive's configuration is read with SET -v,
which is a statement rather than a relation, and the sys tables do not
carry it.

What a second opinion found Copy Section

DeepSeek named three sources and two do not exist:

The third is the most interesting wrong lead in this project so far, because
it is not an invention. sys.SEQUENCE_TABLE is real and the name matches
what was asked for. It holds the metastore's internal identifier allocator:

org.apache.hadoop.hive.metastore.model.MDatabase = 11
org.apache.hadoop.hive.metastore.model.MRole = 11

A model that reports that as Sequences ships a wrong answer that no test
catches, because the query runs and returns rows. A lead that exists is
more dangerous than one that does not, and running it is the only thing that
separates them. See D43.

What the fixture cannot build Copy Section

No index, and that is why Hive is not in the cross family comparison in the
root module. D53 asks every fixture for six core objects and one of them is
an index somebody created. Hive builds five.

No function, because CREATE FUNCTION registers a Java class by name and a
fixture that makes one depends on a class being on the server's path.
Functions is verified to run and returns nothing.

No sequence and no trigger, because Hive has neither.

Every constraint carries DISABLE NOVALIDATE, which Hive requires because
it enforces none of them. They are declarations for a planner and the
queries read them as the catalog records them.

What the conformance test says Copy Section

Hive's section matches PostgreSQL's on every table, view and column, and
differs in two ways that are both facts.

PostgreSQL reports has_default=true on the three serial keys, where Hive
agrees with the other nine databases.

Hive reports extra constraint lines. It records NOT NULL and DEFAULT as
constraints where every other database records them on the column, so a
Hive table has not null and default constraints that the same table
elsewhere does not. Those are additional rows rather than missing ones, and
Columns reports the same facts in the same place as everywhere else.

Which answers depend on who is asking Copy Section

None of them. The image configures no authorization, so a client states a
principal and HiveServer2 takes it, and the server then allows that
principal everything. That is the measurement rather than a gap in it, and
it is the same shape as Trino and Presto.

A Hive with SQL standard authorization configured answers differently
and nothing here measures that, because the image does not configure it.

The describe fields (D209) Copy Section

D198 to D203 gave the root types fields that only PostgreSQL filled. D209 filled
what the metastore has a source for, on 4.2.1 and 4.0.1.

Presto Copy Chapter

Presto is Trino's older self. They forked in 2019 and models/presto is a
model of its own rather than a flavor, which D73 decides and measures. Read
the Trino section first: everything there about a catalog being a real level
and about system.jdbc spanning catalogs is true here too, and this section
records only where the two differ.

What it answers Copy Section

9 of the 65. Catalogs as databases, schemas, tables, columns, views, types,
access methods, privileges and the current user.

Trino answers four more, and each is absent from the product rather than
missing from the model.

Comments has no source. Presto accepts a COMMENT clause on
CREATE TABLE, keeps nothing readable, and shows nothing in
SHOW CREATE TABLE. There is no system.metadata.table_comments for the
query to reach, so Tables.comment and Views.comment are padded absent and
the Comments kind is not registered. COMMENT ON is not a statement Presto
has at all: the parser rejects the word, so a column comment cannot be set
either and system.jdbc.columns.remarks is always NULL.

CurrentSchema has no expression. Neither current_catalog nor
current_schema resolves, and nothing in system.runtime carries the
session. current_user does resolve, so CurrentUser is answered.

Roles and RoleGrants raise rather than answering nothing. This is the
sharpest difference from Trino and the one most likely to surprise. Both
products read the same standard views. Trino's memory connector returns no
rows, which is a supported query with an empty result. Presto's answers:

NOT_SUPPORTED: This connector does not support roles

D34 says a query dbmeta offers must run, so those two are not registered here.
Privileges reads information_schema.table_privileges, which does answer on
the same connector, and returns nothing.

The version query, and why it is not Trino's Copy Section

Presto has no version() function:

Function version not registered

So the model reads the coordinator's row from system.runtime.nodes instead,
with WHERE coordinator = true so that a cluster cannot answer with a
worker's version. usql reads the same table for both products and omits that
filter.

The numbering is the other half of D73. Presto is 0.299-7d50721, which is
release 299 and the build it was cut from. Trino is 483. There is no version
to compare, only a product to tell apart.

One driver, and two vendor clients before it Copy Section

Until 2026-10-07 the test module read the two products through their vendors'
clients, and the two wanted opposite DSNs. prestodb/presto-go-client/v2
took presto://user@host:port/catalog/schema and refused an http:// scheme,
and read any unknown query parameter as a session property. trinodb/ trino-go-client took http:// with the catalog and schema as query
parameters. That was a measure of how far the two had drifted.

dburl v0.43.0 names one package for both schemes, github.com/xo/dbimp/trino,
and dbimp v0.12.0 holds it (D172). It takes trino://user@host:port/catalog/ schema for both products and tells Presto from Trino by GET /v1/info. So the
Trino and Presto entries print that form as their DSN and their URL, and the
tests open the driver name trino for both. The test image takes no password,
so there is no ordinary user.

dbmeta itself is not affected. It depends on nothing and generates its own
DSNs in container, which is D19 and hard rule 1.

What the fixture cannot build Copy Section

Everything Trino cannot, and two more.

No NOT NULL. The memory connector answers "does not support non-null column"
on 0.299, which is the newest release there is, so every column is nullable.
That is the same error that sets Trino's floor at 476, and here there is no
newer release to move to.

No comment of any kind, as above. The view is created without one, because
Presto's CREATE VIEW takes AS or SECURITY after the name and treats
COMMENT as a syntax error rather than accepting and dropping it.

What the conformance test says Copy Section

Presto builds every core object D53 asks for, including the view, with the
same names and ordinals as every other database. Every column reads
nullable=true, which is the fixture difference above, and that is why Presto
has its own section rather than sharing Trino's. It is left out of the
relational agreement count for the same reason Trino is, plus that one.

Which answers depend on who is asking Copy Section

None, the same as Trino and for the same reason. The image configures no
authenticator, a client states a principal on every request, and with no
access control plugin the server allows it everything. Only current_user
differs for a second principal.