SQLancer finds bugs in database systems, and the techniques it introduced have been picked up well beyond the project itself. This page collects what that adds up to, and — more importantly — where each number comes from.

Every figure below is computed from structured records kept in this website's repository under _data/impact/. Each record carries the primary source that justifies it, so any statistic can be followed back to a bug report, a paper, a repository, or a published resource. Nothing on this page is typed in by hand.

  • 2038 bugs attributed to SQLancer and accepted as genuine
  • 41 database systems with SQLancer-attributed bugs
  • 22 DBMS projects with evidence of using SQLancer
  • 209 papers citing a SQLancer publication
  • 30 papers that reuse or extend SQLancer
  • 55 papers that compare against SQLancer

Policy version impact-policy-v1, in force since 2026-09-06. 2130 bug reports are on record; 2038 of them were accepted by the developers as genuine bugs and are what the counts above use.

Bugs found by SQLancer (2038)

A bug counts here when the evidence connects it to SQLancer or to a testing technique SQLancer introduced. Bug reports very often name the test oracle rather than the tool, so a report crediting NoREC, TLP, PQS or QPG counts even when it never says “SQLancer”. Reports the developers rejected as invalid or duplicate stay in the dataset for transparency but are excluded from the totals. The full policy is below.

This is a floor, not a total, and probably a distant one. A bug arrives here only when something public ties it to SQLancer, and most of the testing leaves no such trace: reports against closed-source systems are usually private, a report is written about the bug rather than about what found it, and a project can run SQLancer for years while quietly fixing what it turns up. The dataset can measure part of its own blind spot — 6 of the 22 projects whose own evidence shows them running SQLancer have no bug counted here at all: Feldera, Materialize, NoisePage, SereneDB, XuGu and YDB.

Bugs by database system (41)

Bugs attributed to SQLancer in each database system, each bar split by who found them. Every bar links to that system's own page, which lists the bugs behind the number.

  • Found by the SQLancer project (1408)
  • Found by someone outside the project (541)
  • Reporter not recorded (89)
Bugs found by SQLancer, by database system and who found them Bugs per database system for 40 categories, largest 302, each split by who found them. DuckDB DuckDB — Found by the SQLancer project: 286 DuckDB — Found by someone outside the project: 15 DuckDB — Reporter not recorded: 1 302 SQLite SQLite — Found by the SQLancer project: 222 222 CockroachDB CockroachDB — Found by the SQLancer project: 127 CockroachDB — Found by someone outside the project: 56 CockroachDB — Reporter not recorded: 19 202 StarRocks StarRocks — Found by someone outside the project: 183 183 TiDB TiDB — Found by the SQLancer project: 154 TiDB — Found by someone outside the project: 7 TiDB — Reporter not recorded: 11 172 Dolt Dolt — Found by the SQLancer project: 167 167 MonetDB MonetDB — Found by the SQLancer project: 97 MonetDB — Found by someone outside the project: 42 139 CrateDB CrateDB — Found by the SQLancer project: 81 81 QuestDB QuestDB — Found by the SQLancer project: 53 QuestDB — Found by someone outside the project: 2 55 Umbra Umbra — Found by the SQLancer project: 55 55 Apache DataFusion Apache DataFusion — Found by someone outside the project: 54 54 YugabyteDB YugabyteDB — Found by the SQLancer project: 13 YugabyteDB — Found by someone outside the project: 39 YugabyteDB — Reporter not recorded: 2 54 ClickHouse ClickHouse — Found by the SQLancer project: 7 ClickHouse — Found by someone outside the project: 41 48 MySQL MySQL — Found by the SQLancer project: 32 MySQL — Reporter not recorded: 11 43 H2 H2 — Found by the SQLancer project: 20 20 Apache Doris Apache Doris — Found by the SQLancer project: 3 Apache Doris — Found by someone outside the project: 9 Apache Doris — Reporter not recorded: 7 19 Databend Databend — Found by the SQLancer project: 7 Databend — Found by someone outside the project: 11 18 PostgreSQL PostgreSQL — Found by the SQLancer project: 18 18 Turso Turso — Found by someone outside the project: 18 18 Virtuoso Virtuoso — Found by the SQLancer project: 11 Virtuoso — Found by someone outside the project: 6 17 Citus Citus — Found by the SQLancer project: 1 Citus — Found by someone outside the project: 7 Citus — Reporter not recorded: 8 16 StoneDB StoneDB — Found by the SQLancer project: 12 StoneDB — Reporter not recorded: 4 16 Wadjet Wadjet — Found by someone outside the project: 16 16 MariaDB MariaDB — Found by the SQLancer project: 6 MariaDB — Found by someone outside the project: 1 MariaDB — Reporter not recorded: 8 15 Oxla Oxla — Reporter not recorded: 12 12 TDengine TDengine — Found by the SQLancer project: 12 12 Firebird Firebird — Found by the SQLancer project: 10 10 MatrixOne MatrixOne — Found by someone outside the project: 9 9 RisingWave RisingWave — Found by the SQLancer project: 8 8 BharatDBMS BharatDBMS — Found by someone outside the project: 7 7 CnosDB CnosDB — Found by the SQLancer project: 1 CnosDB — Found by someone outside the project: 4 CnosDB — Reporter not recorded: 2 7 Apache Cloudberry Apache Cloudberry — Found by someone outside the project: 6 6 OceanBase OceanBase — Found by the SQLancer project: 4 4 Presto Presto — Reporter not recorded: 4 4 SeekDB SeekDB — Found by someone outside the project: 3 3 CUBRID CUBRID — Found by the SQLancer project: 1 1 FalkorDB FalkorDB — Found by someone outside the project: 1 1 Hazelcast Hazelcast — Found by someone outside the project: 1 1 Kyzo Kyzo — Found by someone outside the project: 1 1 sparq sparq — Found by someone outside the project: 1 1
Show these figures as a table
Database system Bugs
DuckDB 302
SQLite 222
CockroachDB 202
StarRocks 183
TiDB 172
Dolt 167
MonetDB 139
CrateDB 81
QuestDB 55
Umbra 55
Apache DataFusion 54
YugabyteDB 54
ClickHouse 48
MySQL 43
H2 20
Apache Doris 19
Databend 18
PostgreSQL 18
Turso 18
Virtuoso 17
Citus 16
StoneDB 16
Wadjet 16
MariaDB 15
Oxla 12
TDengine 12
Firebird 10
MatrixOne 9
RisingWave 8
BharatDBMS 7
CnosDB 7
Apache Cloudberry 6
OceanBase 4
Presto 4
SeekDB 3
CUBRID 1
FalkorDB 1
Hazelcast 1
Kyzo 1
sparq 1
TiKV 1

Bugs over time

Bugs by the year they were reported. Each column links to that year's own page, which lists every report behind the number.

Bugs found by SQLancer, by year reported Bugs reported per year across 8 periods, peak 411. 0 150 300 450 600 2019: 221 221 2019 2020: 302 302 2020 2021: 22 22 2021 2022: 224 224 2022 2023: 271 271 2023 2024: 193 193 2024 2025: 264 264 2025 2026: 411 411 2026
Show these figures as a table
Year reported Bugs
2019 221
2020 302
2021 22
2022 224
2023 271
2024 193
2025 264
2026 411

What happened to them

Resolution of the 2038 accepted bug reports.

  • Fixed (1624)
  • Fixed in documentation (13)
  • Confirmed (102)
  • Open (268)
Status of the bugs SQLancer found Bug reports by status: 2007 in 4 states. Fixed: 1624 Fixed 1624 Fixed in documentation: 13 Confirmed: 102 Open: 268
How each bug was attributed Bugs
The report names SQLancer 162
The report names a SQLancer oracle 263
Listed in the project's own bug repository 409
The reproducer carries SQLancer's generated schema 819
Filed by someone who runs SQLancer campaigns 385

Reproducers for the historic reports are kept in the SQLancer bug repository; this page links each record to its upstream report rather than duplicating the test cases.

More bug statistics — which technique found them, which tool, and how each bug manifested.

Database systems

Three things are tracked apart from each other and never conflated: the 21 systems SQLancer ships a testing implementation for, the 41 it has attributed bugs in, and the 22 projects whose own developers use it. Only the last is below; the other two, the system-by-system table and the projects that have proposed adopting SQLancer, are on the database systems page.

Adoption evidence (22)

One entry per project. A project can show up in more than one way — a fork of its own, a job in its CI, a script in its repository — and each project's page carries every piece of evidence in full: the quoted source, what it shows, and when it was last checked.

Project How it uses SQLancer Evidence
Citus official testing 3
ClickHouse official ciofficial testing 4
CnosDB official testing 3
Databend official testing 1
Apache DataFusion official testing 1
DuckDB official testing 1
Feldera official testing 1
Hazelcast official testing 1
Materialize official testing 6
MonetDB official testing 3
NoisePage official testing 1
OceanBase official testing 1
Oxla official testing 1
SeekDB official testing 1
SereneDB official testing 1
sparq official testing 2
StarRocks developer use 1
Turso official testing 6
Wadjet official testing 6
XuGu official testing 1
YDB official testing 1
YugabyteDB official testing 1

9 further projects have proposed adopting SQLancer without anything yet showing them running it. An intention is not use, so those count towards no figure here; they are listed under planned adoption.

Research building on SQLancer (209)

Papers are found by walking the citation graphs of the foundational SQLancer publications, so the list of citing papers is a fact about the graph rather than a judgement. Each paper is then placed in five relationships: that it cites SQLancer, and then whether it reuses the codebase, extends a technique, compares against SQLancer, or calls it the state of the art. The four judgements overlap on purpose — a paper can do several at once — so the totals de-duplicate and such a paper is counted once. Reuse, extension and comparison are what “builds on” means; calling SQLancer the state of the art is recognition, and is counted on its own.

209 papers cite a SQLancer publication, 69 of them do more than cite it, and 34 describe SQLancer or one of its techniques as the state of the art in their own words.

Relationship Papers
Cites SQLancer 209
Uses or extends SQLancer 30
Compares against SQLancer 55
Describes SQLancer as state of the art 34

Papers over time

All papers citing a SQLancer publication, by publication year.

Papers citing SQLancer, by publication year Papers citing SQLancer per year across 7 periods, peak 65. 0 20 40 60 80 2020: 3 3 2020 2021: 17 17 2021 2022: 14 14 2022 2023: 31 31 2023 2024: 33 33 2024 2025: 65 65 2025 2026: 46 46 2026

Papers that go further than citing, by publication year. The categories overlap, so the bars are not additive. The last series is recognition rather than reuse and is not part of the “builds on” total.

  • Uses or extends SQLancer
  • Compares against SQLancer
  • Describes SQLancer as state of the art
How papers relate to SQLancer, by publication year Papers per relationship per year: 3 series across 7 years. 0 5 10 15 20 2020 Compares against SQLancer 2021: 2 2 2021 Uses or extends SQLancer 2022: 5 5 Compares against SQLancer 2022: 4 4 Describes SQLancer as state of the art 2022: 3 3 2022 Uses or extends SQLancer 2023: 5 5 Compares against SQLancer 2023: 5 5 Describes SQLancer as state of the art 2023: 3 3 2023 Uses or extends SQLancer 2024: 5 5 Compares against SQLancer 2024: 11 11 Describes SQLancer as state of the art 2024: 5 5 2024 Uses or extends SQLancer 2025: 10 10 Compares against SQLancer 2025: 19 19 Describes SQLancer as state of the art 2025: 13 13 2025 Uses or extends SQLancer 2026: 5 5 Compares against SQLancer 2026: 14 14 Describes SQLancer as state of the art 2026: 10 10 2026
Show these figures as a table
Year Citing Uses or extends Compares with Builds on (distinct) Calls state of the art
2020 3 0 0 0 0
2021 17 0 2 2 0
2022 14 5 4 8 3
2023 31 5 5 8 3
2024 33 5 11 14 5
2025 65 10 19 23 13
2026 46 5 14 14 10

Papers that build on SQLancer (69)

Grouped by what each paper actually does with SQLancer. Every entry shows the exact passage the classification rests on, copied verbatim from the source. A paper that holds more than one relationship appears in more than one list, so these lists are not additive — the 69 in the summary above counts each paper once.

Uses or extends SQLancer (30)

The paper's implementation reuses or derives from the SQLancer codebase (26 papers), or the authors extend, generalise or adapt a technique introduced through SQLancer — taking TLP to a new data model, say, or building a new method on the PQS idea (8 papers). The two are recorded separately in the data, and each paper's own page says which of them applies.

  • A Set-Theoretic Approach to Detecting Logic Bugs in DBMS Inner Join Optimizations (2026) · IEEE International Conference on Data Engineering
    The test case generation is built on SQLancer, which the authors extend so that all generated columns are NOT NULL, and it relies on SQLancer's randomised population of predicates and clauses. TLP is both its closest conceptual relative -- the paper says both rest on set-theoretic principles -- and one of the two approaches it is measured against, with each JoinEquiv bug rewritten into TLP and DQP form to see whether they reproduce it. Written by claude-opus-5 from the 43 places this paper refers to SQLancer. See the evidence.
    The test case generation builds upon the SQLancer framework, which provides a grammar-aware SQL query generation engine. — source
    We extend SQLancer to satisfy an additional precondition that all columns are NOT NULL. — source
    Also: compares with.
  • EPSC: Testing Database Management Systems via Equivalent Prepared Statement Construction (2026) · Proceedings of the ACM on Management of Data
    EPSC reuses SQLancer's statement generators to produce the statements it then rewrites into prepared form, and takes four oracles as baselines, two of which -- NoREC and TLP -- are SQLancer's, alongside CODDTest, which also came out of the project. Written by claude-opus-5 from the 30 places this paper refers to SQLancer. See the evidence.
    We reused the statement generators from SQLancer [ 27] for statement generation, which are manually written and rule-based. — source
    Also: compares with.
  • Finding Performance Issues in Database Systems by Exploiting Dormant Code Paths (2026) · arXiv.org
    SQLancer is used two ways. It supplies the workload: the authors collected ten thousand randomly generated small workloads from it, described as a popular DBMS testing tool, and those are the queries QueryZen runs against the flipped branches. Separately, CERT is one of four prior performance-testing methods QueryZen is measured against, and the comparison is reported issue by issue -- of the 21 issues found, 4 could potentially have been found by CERT, and 21 of 21 already existed when CERT was published. Note that SQLancer here generates input for a different technique rather than being the thing QueryZen is built on. Written by claude-opus-5 from the 18 places this paper refers to SQLancer. See the evidence.
    In this paper, we collected 10 thousand randomly generated small workloads from SQLancer[27, 28], which is a popular DBMS testing tool. — source
    Also: compares with.
  • LLMSQLMUTATOR: LLM-Powered Test Case Generation for Database Using Bug Reports (2026) · IEEE International Conference on Data Engineering
    SQLancer is both a baseline and a component. As a baseline it is one of four tools compared over 48 hours, and the paper is even-handed: SQLancer's syntactic correctness exceeds 90% on every system tested, higher than the mutation-based tools, while its coverage peaks around 52%. It is called the most effective black-box fuzzing tool, distinguished by its three complementary oracles. Those oracles are also reused directly: for test cases containing SELECT queries, LLMSQLMutator randomly selects one of TLP, NoREC or CERT as its oracle, describing them as the three most effective existing oracles for detecting result inconsistency. Of its 14 result-inconsistency bugs, TLP found 12 and CERT the other two. Written by claude-opus-5 from the 14 places this paper refers to SQLancer. See the evidence.
    2) For test cases containing SELECT queries, we employ result inconsistency detection by randomly selecting one test oracle from TLP [13], NoREC [12], or CERT [44]. — source
    We selected the three most effective existing oracles for detecting logic bugs through result inconsistency: NoREC [12], TLP [13], and CERT [44]. — source
    Also: compares with.
  • A Comprehensive Study of Bugs in Relational DBMS (2025) · IEEE Transactions on Software Engineering
    SQLancer is both the study's reference generator and the base of its proof-of-concept tool. The study repeatedly measures bug-triggering SQL against what SQLancer can generate -- it does not support partition-related syntax at all, and it lacks bias toward diverse data types or high-risk constructs such as nested casts. SQLT is then built as an extension of SQLancer, adding BIT and JSON support that SQLancer under-supported, and running NoREC and TLP as its oracles. The two are compared directly over 24 hours on MySQL and SQLite, where SQLT found 6 bugs to SQLancer's 4, including one in MySQL that SQLancer did not reach. Written by claude-opus-5 from the 17 places this paper refers to SQLancer. See the evidence.
    Design and Motivation of SQLTSQLT is an extension of the widely-used database testing tool, SQLancer [12]. — source
    SQLT extends SQLancer by introducing new data types such as BIT and JSON, which were undersupported by SQLancer. — source
    Also: compares with.
  • Anomaly Pattern-guided Transaction Bug Testing in Relational Databases (2025) · arXiv.org
    APTrans's database and SQL generation is SQLancer's, extended. The paper states it develops its generation method based on SQLancer and builds on the SQLancer framework, extending it to support table joins in both database and statement generation, because the base version generates isolated tables and real workloads involve tables connected by join keys. Type constraints were added for the same reason, since SQLancer's expressions produce many semantic errors from type mismatches. Those generated statements and databases are then the input to the anomaly-pattern constraint solver, which is APTrans's own. Its baselines are TxCheck and Troc rather than any SQLancer oracle. Written by claude-opus-5 from the 14 places this paper refers to SQLancer. See the evidence.
    We develop our database and SQL statement generation method based on SQLancer [ 4] and extend it to support table join operations for both database generation and SQL statement generation. — source
    To simulate real-world scenarios, which usually involve multiple tables connected with join keys, we extend SQLancer to support table join operations for both database generation and SQL statement generation. — source
  • ARG: Testing Query Rewriters via Abstract Rule Guided Fuzzing (2025) · International Conference on Automated Software Engineering
    ARG integrates SQLancer to construct dynamic database schemas and populate them, and then measures itself against it, reporting 1017% more rewrite rules triggered and 15 more bugs in 24 hours. Written by claude-opus-5 from the 21 places this paper refers to SQLancer. See the evidence.
    To generate DDL statements and enhance abstract rule extraction, we integrated SQLancer to construct dynamic database schemas and populate test data. — source
    Also: compares with.
  • Automated Discovery of Test Oracles for Database Management Systems Using LLMs (2025) · Proceedings of the ACM on Management of Data
    Argus uses SQLancer++'s query generator to produce seed queries while deliberately not using its predefined oracles, since discovering oracles is the paper's own subject. It measures itself against SQLancer, SQLancer++ and EET on coverage, and calls SQLancer a state-of-the-art open-source DBMS testing framework. Its artifact carries SQLancer's own source files. Written by claude-opus-5 from the 59 places this paper refers to SQLancer. See the evidence.
    Its artifact, joyemang33/Argus, shows SQLancer markers.
    Repository names this paper. source
    MetamorphicCoverageArtifact/Code/mc-guided_fuzzing/src/sqlancer/Randomly.java is SQLancer's Randomly.java, but it sits under MetamorphicCoverageArtifact, which looks like a bundled copy of another project source
    These snippets can be generated offline by a hybrid approach combining an LLM to cover diverse database features and a high-throughput generator, such as SQLancer [ 49], even though the prover currently cannot reason about them. — source
    Also: compares with.
  • Fucci: Database Transaction Fuzzing via Random Conflict Construction and Multilevel Constraint Solving (2025) · Proceedings of the VLDB Endowment
    Its artifact reuses the SQLancer codebase, carrying the approach into transaction testing. Summary written by claude-opus-5 from abstract; the quotations below are the paper's own words.
    Its artifact, Reverie4u/Fucci, carries them under a renamed package, and contains SQLancer's own source files.
    Repository names this paper. source
    src/main/java/fucci/Randomly.java is SQLancer's Randomly.java, with the package renamed to fucci (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
  • Reproducibility Report for ACM SIGMOD 2025 Paper: 'Constant Optimization Driven Database System Testing' (2025)
    This paper is a reproduction of SQLancer work rather than a citation of it. CODDTest is implemented inside SQLancer -- the report states the tool works by integrating the method with SQLancer, and that the SQLancer repository acknowledges the work as a supported testing method -- so reproducing it meant running a version of SQLancer that supports the method, from the authors' artifacts. The comparison it verifies is between three oracles in that one tool: CODDTest, NoREC and query partitioning, all executed through SQLancer against SQLite. Written by claude-opus-5 from the 13 places this paper refers to SQLancer. See the evidence.
    •The tool works by integrating their method with SQLancer [ 1], a tool to automatically test databases. — source
    The SQLancer github repo also acknowledges the author’s work as a supported testing method. — source
    Also: compares with.
  • Sembug: Detecting Logic Bugs in Dbms Through Generating Semantic-Aware Non-Optimizing Query (2025) · IEEE International Conference on Program Comprehension
    SemBug is a direct descendant of NoREC: it says it transforms the optimized query into a less optimized one 'inspired by NoREC', and its evaluation treats NoREC, TLP and Pinolo as the state-of-the-art techniques to beat. It also runs on SQLancer's own machinery, using it as the query generator, and its artifact carries SQLancer's source under a renamed package. Written by claude-opus-5 from the 84 places this paper refers to SQLancer. See the evidence.
    Its artifact, Syang111/SemBug, carries them under a renamed package, and contains SQLancer's own source files.
    Repository is named after Sembug, the tool this paper says it built, and is about database testing. source
    src/Sonar/Randomly.java is SQLancer's Randomly.java, with the package renamed to Sonar (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    We use SQLancer [29], a rule-based method for query generation. — source
    Also: extends technique, compares with.
  • Simple Testing Can Expose Most Critical Transaction Bugs: Understanding and Detecting Write-Specific Serializability Violations in Database Systems (2025) · Proceedings of the VLDB Endowment
    Extends the idea of a general correctness property checkable without a reference implementation from queries to transactions, and its artifact reuses the SQLancer codebase. Summary written by claude-opus-5 from abstract; the quotations below are the paper's own words.
    We implement WriteCheck based on SQLancer [ 14], and extend SQLancer to detect WSSviolations. — source
    Also: extends technique.
  • SRS: Detecting Logic Bugs of Join Implementation in DBMSs via Set Relation Synthesis (2025) · Proc. ACM Manag. Data
    SRS is implemented on SQLancer, generating its database state with SQLancer's syntax-rule-based random generation and keeping SQLancer's query generation strategy for features outside the join. SQLancer's oracles are then also its baselines: PQS, NoREC, TLP and DQP are four of the six approaches it is measured against, and it reports finding 9 to 12 more bugs than each. Written by claude-opus-5 from the 59 places this paper refers to SQLancer. See the evidence.
    SRS applies the automated, syntax-rule-based random generation approach of SQLancer to ensure that the database state exhibits sufficient diversity, thereby enabling thorough and effective bug detection. — source
    For the generation of other language features, aside from considering the tables involved in joins, our approach remains consistent with SQLancer’s query generation strategy for NoREC test oracle [23]. — source
    Also: compares with.
  • Chronos: Finding Timeout Bugs in Practical Distributed Systems by Deep-Priority Fuzzing with Transient Delay (2024) · IEEE Symposium on Security and Privacy
    SQLancer serves as a workload generator, not an oracle: it produces the SQL workload used to exercise MySQL-Cluster while Chronos injects delays around it. The artifact carries SQLancer source content, consistent with it being bundled for that purpose. The bugs reported are timeout bugs found by delay injection, not logic bugs found by a SQLancer oracle. Written by claude-opus-5 from the 1 place this paper refers to SQLancer. See the evidence.
    Its artifact, SecTechTool/Chronos, contains SQLancer's own source files.
    Repository is named after Chronos, the tool this paper says it built, and is about database testing. source
    workload/mysql-cluster/sqlancer/src/sqlancer/Randomly.java is SQLancer's Randomly.java (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    For MySQL-Cluster, the workload is generated by SQLancer [57], one of the widely used SQL generators for testing database systems. — source
  • DBStorm: Generating Various Effective Workloads for Testing Isolation Levels (2024) · International Symposium on Software Testing and Analysis
    SQLancer supplies DBStorm's SQL. The paper states that because SQLancer targets the relational model it is used to generate syntactically and semantically correct SQL operations, and that since SQLancer mainly produces serially executed operations they revised it to generate parallel ones. It is also one of the tools measured against, and the comparison makes the paper's point precisely: SQLsmith, SQLancer and Squirrel between them reveal 760 bugs of which none is an isolation bug, because they execute transactions sequentially in a single thread and so cannot produce a cycle in the conflict graph at all. Written by claude-opus-5 from the 17 places this paper refers to SQLancer. See the evidence.
    As SQLancer [60] targets for the relational model, we leverage it to generate syntax/semantic correct SQL operations. — source
    Since SQLancer mainly generates serially executed operations, we revise it to generate parallel operations. — source
    Also: compares with.
  • Detecting Logical Bugs in DBMS via Isomerism Fuzz System (2024) · 2024 6th International Academic Exchange Conference on Science and Technology Innovation (IAECST)
    The system is built inside SQLancer: the paper states it was implemented within SQLancer, and that its query generation draws on SQLancer's design principles with modifications. NoREC and query partitioning are described as the prior techniques it extends the reach of. The sentence establishing this is letter-spaced in the PDF's text layer, so it reads as separated characters; the words are intact. Written by claude-opus-5 from the 6 places this paper refers to SQLancer. See the evidence.
    The query generation approach draws on the design principles of SQLancer [16], with certain modifications. — source
  • Detecting Metadata-Related Logic Bugs in Database Systems via Raw Database Construction (2024) · Proceedings of the VLDB Endowment
    A metamorphic oracle for DBMS logic bugs whose artifact reuses the SQLancer codebase. Summary written by claude-opus-5 from abstract; the quotations below are the paper's own words.
    Its artifact, JensonSung/radar, includes SQLancer's Randomly.java, and retains SQLancer source files, and builds under SQLancer's own build coordinates, and keeps SQLancer's package layout, and keeps SQLancer's database-system providers.
    Repository names this paper. source
    Repository retains SQLancer source files: src/sqlancer/Randomly.java, src/sqlancer/Main.java, src/sqlancer/common/oracle/TestOracle.java source
    pom.xml identifies the project as SQLancer. source
  • Semantic Conformance Testing of Relational DBMS (2024) · Proceedings of the VLDB Endowment
    SEMCONT is built on SQLancer, whose syntax-guided generation it enhances with coverage guidance and uses as the seed pool for its own query generation. TLP and NoREC are then its baselines, described as state-of-the-art metamorphic testing methods and run in both their SQLancer and SQLRight implementations. Written by claude-opus-5 from the 42 places this paper refers to SQLancer. See the evidence.
    Here, we 10 enhance the syntax-guided generation method, SQLancer [14], with coverage-guided test case generation. — source
    We adopt SQLancer to randomly generatea large number of SQL statements (line 2), which serves as the seed pool of our query generation algorithm. — source
    Also: compares with.
  • Detecting Isolation Bugs via Transaction Oracle Construction (2023) · International Conference on Software Engineering
    SQLancer supplies Troc's generation and defines the gap Troc fills. The paper states that Troc's database and SQL statement generation is mainly based on SQLancer, and that the schema features it works with -- primary keys, indexes, data types and conditions -- are those SQLancer supports. SQLancer is also among the tools measured against, where the paper's point is structural: it and SQLsmith cannot generate transaction test cases and have no oracle for them, so isolation bugs are outside their reach entirely. PQS, TLP, NoREC and QPG are described as the single-query oracles this work is positioned beyond. Written by claude-opus-5 from the 12 places this paper refers to SQLancer. See the evidence.
    Its artifact, criszy/Troc, carries them under a renamed package, and contains SQLancer's own source files.
    Repository names this paper. source
    src/main/java/troc/Randomly.java is SQLancer's Randomly.java, with the package renamed to troc (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    Troc’s database and SQL statement generation mainly bases on SQLancer [49]. — source
    Also: compares with.
  • GDsmith: Detecting Bugs in Cypher Graph Database Engines (2023) · International Symposium on Software Testing and Analysis
    GDsmith says plainly that its framework is derived from SQLancer, carrying that tool's approach from relational engines to Cypher, and its artifact holds SQLancer's source under a renamed package. PQS, NoREC and TLP are summarised as the relational oracles that came before it. Written by claude-opus-5 from the 4 places this paper refers to SQLancer. See the evidence.
    Its artifact, ddaa2000/GDsmith, carries them under a renamed package, and contains SQLancer's own source files.
    Repository is named after GDsmith, the tool this paper says it built, and is about database testing. source
    src/main/java/org/example/gdsmith/Randomly.java is SQLancer's Randomly.java, with the package renamed to org.example.gdsmith (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    Its framework is derived from SQLancer [ 18] (which is a tool to automatically test relational database engines). — source
  • Testing Database Systems via Differential Query Execution (2023) · International Conference on Software Engineering
    DQE is built on SQLancer. The paper states that its implementation is based on SQLancer and that its database generation is mainly adopted from it, and it notes that DQE, PQS, NoREC and TLP are all built on SQLancer and so share similar query generation -- offered as the explanation for their comparable code coverage. PQS, NoREC and TLP are also its baselines: it reports coverage and bug counts against all three, and its motivation is that none of them can be applied to UPDATE and DELETE statements, which is the gap DQE fills. Written by claude-opus-5 from the 21 places this paper refers to SQLancer. See the evidence.
    Its artifact, JensonSung/dqetool, carries them under a renamed package, and contains SQLancer's own source files.
    Repository names this paper. source
    src/dqetool/Randomly.java is SQLancer's Randomly.java, with the package renamed to dqetool (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    Our database generation is mainly adopted from SQLancer [27]. — source
    Also: compares with.
  • Testing Graph Database Systems via Graph-Aware Metamorphic Relations (2023) · Proceedings of the VLDB Endowment
    Extends metamorphic query transformation, the basis of SQLancer's oracles, with graph-specific relations, and its artifact reuses the SQLancer codebase. Summary written by claude-opus-5 from abstract; the quotations below are the paper's own words.
    Its artifact, cuhk-seclab/Gamera, carries them under a renamed package, and contains SQLancer's own source files.
    Repository names this paper. source
    GremlinChecker/src/main/java/org/gdbtesting/Randomly.java is SQLancer's Randomly.java, with the package renamed to org.gdbtesting (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    Also: extends technique.
  • Detecting Logical Bugs of DBMS with Coverage-based Guidance (2022) · USENIX Security Symposium
    SQLRight is built on SQLancer and Squirrel, and two of its four oracles -- NoREC and TLP -- are ported from SQLancer directly. It then measures itself against SQLancer as the state-of-the-art oracle-based tool, reporting more bugs but acknowledging SQLancer's much higher query validity. Written by claude-opus-5 from the 83 places this paper refers to SQLancer. See the evidence.
    Its artifact, PSU-Security-Universe/sqlright-artifact, contains SQLancer's own source files.
    Repository names this paper. source
    MySQL/docker/sqlancer/sqlancer/src/sqlancer/Randomly.java is SQLancer's Randomly.java (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    Our implementation is based on Squirrel [71] and SQLancer [30]. — source
    Also: extends technique, compares with.
  • Differentially Testing Database Transactions for Fun and Profit (2022) · International Conference on Automated Software Engineering
    DT2 generates its databases and transactions mainly on the basis of SQLancer, revised for the transaction setting, and its artifact carries SQLancer's source under a renamed package. PQS, NoREC and TLP are cited as the approaches confined to single SELECT statements -- the limitation DT2 sets out to pass. Written by claude-opus-5 from the 3 places this paper refers to SQLancer. See the evidence.
    Its artifact, criszy/DT2, carries them under a renamed package, and contains SQLancer's own source files.
    Repository is named after DT2, the tool this paper says it built, and is about database testing. source
    src/DT2/Randomly.java is SQLancer's Randomly.java, with the package renamed to DT2 (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    We generate them mainly based on SQLancer [ 16], and slightly revise the approach for our target. — source
  • Finding bugs in Gremlin-based graph database systems via Randomized differential testing (2022) · International Symposium on Software Testing and Analysis
    SQLancer's three oracles are the relational precedent Grand carries into graph databases, each described in its related work. The reuse goes further than the text says: Grand's repository holds SQLancer's own source under a renamed package, which is the only evidence of it. Written by claude-opus-5 from the 7 places this paper refers to SQLancer. See the evidence.
    Its artifact, choeoe/Grand, carries them under a renamed package, and contains SQLancer's own source files.
    Repository is named after Grand, the tool this paper says it built, and is about database testing. source
    src/main/java/org/gdbtesting/Randomly.java is SQLancer's Randomly.java, with the package renamed to org.gdbtesting (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    Artifact https://github.com/choeoe/Grand carries: renamed_sqlancer_package, sqlancer_source_content_match — source
  • GDsmith: Detecting Bugs in Graph Database Engines (2022) · arXiv.org
    GDsmith says plainly that its framework is derived from SQLancer, carrying that tool's approach from relational engines to Cypher, and its artifact holds SQLancer's source under a renamed package. PQS, NoREC and TLP are summarised as the relational oracles that came before it. Written by claude-opus-5 from the 4 places this paper refers to SQLancer. See the evidence.
    Its artifact, ddaa2000/GDsmith, carries them under a renamed package, and contains SQLancer's own source files.
    Repository is named after GDsmith, the tool this paper says it built, and is about database testing. source
    src/main/java/org/example/gdsmith/Randomly.java is SQLancer's Randomly.java, with the package renamed to org.example.gdsmith (8 of 8 identifiers match: StringGenerationStrategy, SOPHISTICATED, cachedLongs, cachedStrings, cachedDoubles). source
    Its framework is derived from SQLancer [ 23] (which is a tool to automatically test relational database engines). — source
  • DIRT: Database-Integrated Random Testing (2026) · DBTest@SIGMOD
    DIRT takes SQLancer as both its point of departure and its baseline: three of its five oracles are reimplementations of SQLancer's, expressed as generation actions, and it explicitly declines to modify SQLancer itself, arguing that integrating a new DBMS into it is too laborious for a system under active development. It is careful to say that outperforming SQLancer on Turso does not mean it has better generators or oracles. Written by claude-opus-5 from the 63 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)Ternary Logic Partitioning (TLP)
    1 Definitions of Oracles in DIRT In this subsection, we go over definitions of five different oracles written as sequences of generation actions, three of which are reimplementations of existing oracles in SQLancer. — source
    We start by defining the first of the three SQLancer oracles we implemented, Pivoted Query Synthesis (PQS) [ 23], as a universally quantified proposition in Fig. — source
    Also: compares with.
  • QTRAN: Extending Metamorphic-Oracle Based Logical Bug Detection Techniques for Multiple-DBMS Dialect Support (2025) · Proc. ACM Softw. Eng.
    SQLancer's oracles are precisely what QTRAN extends: NoREC and TLP are two of the four state-of-the-art techniques it takes and carries to eight DBMSs, and the paper tabulates which systems each currently supports to show the gap it closes. SQLancer is also its measure of the per-DBMS adaptation cost. Written by claude-opus-5 from the 22 places this paper refers to SQLancer. See the evidence.

    Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    In our evaluation, we selected four state-of-the-art MOLT s for extension: NoRec [ 37], TLP [38], Pinolo [20], and DQE [44]. — source
    Below, we detail each of these tools: (1)NoRec [37]: This technique involves transferring predicates from the WHERE clause to the SELECT clause. — source
  • Retromorphic Testing: A New Approach to the Test Oracle Problem (2023) · arXiv.org
    PQS is the paper's worked example of its own concept: the authors argue that although PQS was described as a technique for a specific system, it is an instance of retromorphic testing, and record that an author of PQS agreed with that categorisation. Written by claude-opus-5 from the 6 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)
    Although the original paper describes PQS as a testing technique for a specific system, we think it can be regarded as an instance of the general Retromorphic Testing methodology. — source
    We also discussed with one author of PQS and he agrees that PQS should be categorized as a Retromorphic Testing technique. — source
  • A Disjoint-Partitioning Approach to Enhancing Metamorphic Testing of DBMS (2022) · 2022 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW)
    The paper is built entirely on SQLancer's work: it devotes a section to query partitioning and ternary logic partitioning, identifies a gap between the two, and introduces disjoint partitioning to close it. That gap-closing is the paper's whole contribution. Written by claude-opus-5 from the 8 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    They proposed the query partitioning (QP) and ternary logic partitioning (TLP) techniques. — source
    We find a gap between QP and TLP, and introduce the concept of disjoint partitioning to address the issue. — source

Compares against SQLancer (55)

The paper evaluates its own approach against SQLancer or one of its test oracles as a baseline.

  • A Comprehensive Survey on Database Management System Fuzzing: Techniques, Taxonomy and Evaluation (2026) · ACM Computing Surveys
    SQLancer's oracles are among the principal subjects of the survey: PQS, NoREC, TLP and QPG each get their own pipeline description, and the experimental section runs them against one another, reporting for instance that QPG detects bugs more efficiently than TLP within 240 minutes. Written by claude-opus-5 from the 73 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)Query Plan Guidance (QPG)
    Within 240 minutes, QPG detects bugs more efficiently than TLP, and the number of detected bugs gradually converges in the later stage, demonstrating that query plan feedback effectively improves the efficiency of logic bug detection. — source
  • A Set-Theoretic Approach to Detecting Logic Bugs in DBMS Inner Join Optimizations (2026) · IEEE International Conference on Data Engineering
    The test case generation is built on SQLancer, which the authors extend so that all generated columns are NOT NULL, and it relies on SQLancer's randomised population of predicates and clauses. TLP is both its closest conceptual relative -- the paper says both rest on set-theoretic principles -- and one of the two approaches it is measured against, with each JoinEquiv bug rewritten into TLP and DQP form to see whether they reproduce it. Written by claude-opus-5 from the 43 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)Differential Query Plans (DQP)
    Within each thread, for every INNER JOINquery, JoinEquiv, TLP, and DQP are applied sequentially under the same system TABLE IISUMMARY OFLOGICBUGREPORTS ANDVERIFICATIONSTATUS INDIFFERENTRDBMSS RDBMS Reported Verified Fixed Intended Component Severity Identifier MySQL 10 8 1 2 Optimizer (8) Critical (8)Bug#118544, Bug#118684, Bug#118710, Bug#118857, Bug#118858, Bug#118949, Bug#119032, Bug#119059 ... — source
    Comparison to Existing DBMS Testing Approaches In order to evaluate JoinEquiv’s unique ability to detect logical bugs related to INNER JOIN, we compare it with two representative metamorphic testing approaches: Ternary Logic Partitioning (TLP) and Differential Query Plans (DQP). — source
    Also: uses infrastructure.
  • BugForge: Constructing and Utilizing DBMS Bug Repository to Enhance DBMS Testing (2026) · arXiv.org
    SQLancer is one of two state-of-the-art tools BugForge is compared against, run in its FUZZ mode, with branch coverage and bug counts reported per DBMS -- 441,160 branches to SQLancer's 201,299, and 18 bugs to its 11 over the three jointly supported systems. MonetDB is excluded from the totals because SQLancer does not support it. Written by claude-opus-5 from the 10 places this paper refers to SQLancer. See the evidence.
    For SQLancer, we enable its FUZZ mode for testing. — source
    Overall,BugForge outperforms both SQLancer and SQLsmith in branch coverage across all evaluated DBMSs. — source
  • DBcover: A White-box SQL Test Generation Framework for Coverage Improvement (2026)
    ShQveL, which enhances SQLancer++ with LLM-synthesised SQL fragments, is one of DBcover's baselines and is reported to achieve substantially lower coverage because it lacks the seed corpus and context DBcover uses. SQLancer itself is cited as an early syntax-driven generator. Written by claude-opus-5 from the 10 places this paper refers to SQLancer. See the evidence.
    •ShQveL [ 34] enhances existing SQL test case generator (SQLancer++ [ 33]) by leveraging LLM to synthesize SQL fragments. — source
    ShQveL—a standalone LLM-augmented generator that does not leverage the seed corpus—achieves substantially lower coverage (31. — source
  • Detecting DBMS Bugs by Constructing Equivalent Representations of Intermediate Query Results (2026)
    TLP is one of ERIQ's four baselines, named among state-of-the-art DBMS logic-bug detection approaches alongside EDC, Radar and EET, and included partly because EDC's own evaluation used it. The comparison is a careful one: rather than running each tool, the authors reconstruct test cases from each approach's relation and construction procedure starting from the same minimised cases. TLP detected 9 of ERIQ's 54 bugs -- more than any other baseline, and still a sixth of the total. PQS, NoREC and TLP are each described in related work as the query-level oracles ERIQ is positioned against. Written by claude-opus-5 from the 18 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    We selected 4 state-of-the-art DBMS logic bug detection approaches as baselines: EDC [ 4], Radar [ 34], EET [ 11], and TLP [ 30]. — source
    DBMSERIQ EDC Radar EETTLP MySQL 26 4 4 5 6 MariaDB 11 2 1 1 3 Percona 13 2 1 0 0 OceanBase 4 0 0 0 0 Total 54 8 6 6 9 Among the 54 unique logic bugs detected by ERIQ, EDC, Radar, EET, and TLP could detect 8, 6, 6, and 9 bugs, respectively, corresponding to 14. — source
  • DIRT: Database-Integrated Random Testing (2026) · DBTest@SIGMOD
    DIRT takes SQLancer as both its point of departure and its baseline: three of its five oracles are reimplementations of SQLancer's, expressed as generation actions, and it explicitly declines to modify SQLancer itself, arguing that integrating a new DBMS into it is too laborious for a system under active development. It is careful to say that outperforming SQLancer on Turso does not mean it has better generators or oracles. Written by claude-opus-5 from the 63 places this paper refers to SQLancer. See the evidence.
    We evaluate DIRTon Turso, an actively developed SQLite-compatible OLTP engine, and show that it finds 23 unique, confirmed bugs–significantly outperforming off-the-shelf SQLancer variants in terms of true positive rate and usefulness of bug reports. — source
    This does not mean that DIRThas better generators or oracles than SQLancer. — source
    Also: extends technique.
  • Efficiently Detecting DBMS Bugs through Bottom-up Syntax-based SQL Generation (2026) · Network and Distributed System Security Symposium
    SQLancer is the paper's reference point for the template-based approach it is arguing against, and it is unusually direct about SQLancer's standing: the most advanced tool in the category, and the most popular platform for implementing the latest SQL testing techniques. Its baselines are two of those techniques rather than SQLancer's own oracles -- SQLancer+QPG on CockroachDB and SQLancer+DQP on MySQL and MariaDB -- and the paper notes both are built on top of SQLancer and use its SQL templates. The critique is that those hand-written Java templates bound which SQL features can appear at all, which is the limitation the grammar-based generation is meant to remove. Written by claude-opus-5 from the 19 places this paper refers to SQLancer. See the evidence.

    Query Plan Guidance (QPG)Differential Query Plans (DQP)
    In this evaluation, we include two of the latest and most advanced testing techniques implemented in SQLancer which are capable of detecting DBMS memory errors, i. — source
    , SQLancer +QPG[52] and SQLancer +DQP[53]. — source
  • EPSC: Testing Database Management Systems via Equivalent Prepared Statement Construction (2026) · Proceedings of the ACM on Management of Data
    EPSC reuses SQLancer's statement generators to produce the statements it then rewrites into prepared form, and takes four oracles as baselines, two of which -- NoREC and TLP -- are SQLancer's, alongside CODDTest, which also came out of the project. Written by claude-opus-5 from the 30 places this paper refers to SQLancer. See the evidence.

    Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)Constant-Optimization-Driven Testing (CODDTest)
    For our evaluation, we chose NoREC [ 25], TLP [ 26], DQE [ 31], and CODDTest [ 35] as baseline approaches. — source
    Specifically, NoREC and DQE represent the class of approaches that detect logic bugs by leveraging clause equivalence; TLP represents the set-relation–based oracle design. — source
    Also: uses infrastructure.
  • Finding Missed Optimizations in DBMSs through Unbalanced Short-circuit Query Construction (2026) · Proceedings of the ACM on Management of Data
    CERT is SCor's most direct comparison, one of five performance-bug detection tools it is measured against and described as tackling performance bugs through cardinality estimation analysis. SCor found 36 more bugs than CERT, and the paper gives a precise account of the difference in reach: CERT cannot detect optimization opportunities that persist despite correct cardinality estimates, which is exactly the class short-circuit construction targets. SQLancer also appears as a data-generation source the paper declines to reimplement, listing it among the existing methods available for producing test data. Written by claude-opus-5 from the 14 places this paper refers to SQLancer. See the evidence.

    Cardinality Estimation Restriction Testing (CERT)
    We compared SCor with five state-of-the-art DBMS performance bug detection tools, including: APOLLO [ 18], AMOEBA [ 24], and CERT [ 1], Puppy [ 54], and HULK [ 55]. — source
    The results show that SCor found 24, 8, 36, 8, and 4 more bugs than APOLLO, AMOEBA, CERT, Puppy, and HULK, respectively. — source
  • Finding Performance Issues in Database Systems by Exploiting Dormant Code Paths (2026) · arXiv.org
    SQLancer is used two ways. It supplies the workload: the authors collected ten thousand randomly generated small workloads from it, described as a popular DBMS testing tool, and those are the queries QueryZen runs against the flipped branches. Separately, CERT is one of four prior performance-testing methods QueryZen is measured against, and the comparison is reported issue by issue -- of the 21 issues found, 4 could potentially have been found by CERT, and 21 of 21 already existed when CERT was published. Note that SQLancer here generates input for a different technique rather than being the thing QueryZen is built on. Written by claude-opus-5 from the 18 places this paper refers to SQLancer. See the evidence.

    Cardinality Estimation Restriction Testing (CERT)
    We considered the performance issues found by the four existing performance-testing methods:APOLLO[16],AMOEBA[21],CERT[1], and PUPPY[40]. — source
    We considered the same performancetesting methods in Section 3:APOLLO[16],AMOEBA[21], CERT[1], and PUPPY[40]. — source
    Also: uses infrastructure.
  • FuzzySQL: Uncovering Hidden Vulnerabilities in DBMS Special Features with LLM-Driven Fuzzing (2026) · arXiv.org
    SQLancer is one of three state-of-the-art open-source baselines, alongside Squirrel and EET. The comparison required accommodation in both directions: because SQLancer is not a grey-box tool, the authors collected its generated test cases and replayed them through FuzzySQL's own mechanism to measure coverage, and because SQLancer pairs different oracles with different systems they ran TLP for MySQL and NoREC for the other targets. That constraint is noted as a property of SQLancer's design rather than a shortcoming. Bug counts are reported per target over 24 hours. Written by claude-opus-5 from the 11 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)Non-optimizing Reference Engine Construction (NoREC)
    To demonstrate the advantage of FuzzySQL, we compare it against three state-of-the-art opensource fuzzing baselines: Squirrel [ 56], EET [ 19], and SQLancer [ 35]. — source
    Since EET and SQLancer are not inherently a grey-box fuzzing tool, we first collect their generated test cases and then utilize FuzzySQL’s replay mechanism to measure its coverage. — source
  • LLMSQLMUTATOR: LLM-Powered Test Case Generation for Database Using Bug Reports (2026) · IEEE International Conference on Data Engineering
    SQLancer is both a baseline and a component. As a baseline it is one of four tools compared over 48 hours, and the paper is even-handed: SQLancer's syntactic correctness exceeds 90% on every system tested, higher than the mutation-based tools, while its coverage peaks around 52%. It is called the most effective black-box fuzzing tool, distinguished by its three complementary oracles. Those oracles are also reused directly: for test cases containing SELECT queries, LLMSQLMutator randomly selects one of TLP, NoREC or CERT as its oracle, describing them as the three most effective existing oracles for detecting result inconsistency. Of its 14 result-inconsistency bugs, TLP found 12 and CERT the other two. Written by claude-opus-5 from the 14 places this paper refers to SQLancer. See the evidence.
    2) Comparsion of baselines We compare LLMSQLM UTATOR with state-of-the-art DBMS testing approaches, including mutation-based methods SQLRight [15] and Squirrel [16], as well as grammar-based SQLancer [11] and random-based SQLsmith [6] to provide a comprehensive empirical comparison. — source
    TABLE VI: The bug number and bug pattern covered by SQLsmith, SQLancer, SQLRight, Squirrel and LLMSQLM UTATOR in 48h DBMSSQLsmith SQLancer Squirrel SQLRight LLMSQLM UTATOR #Bug Pattern #Bug Pattern #Bug Pattern #Bug Pattern #Bug Pattern MySQL - - 1 23. — source
    Also: uses infrastructure.
  • One DBMS, Two Modes, and a Bunch of Bugs: Catching Logic Bugs in Distributed DBMSs via Differential Testing (2026) · Proceedings of the ACM on Management of Data
    QPG is DistSQL's closest comparison and its point of departure. The paper describes QPG as improving SQLancer by using query plan text as feedback to mutate the database state when no new plans appear, and argues this focuses on centralized database state and so becomes noisy and less informative on distributed systems. That claim is tested directly: one of DistSQL's own ablation variants uses query-plan-text feedback identical to QPG's, and QPG is also run as an external baseline alongside Jepsen, Mallory and EET, with DistSQL finding 28 more bugs. NoREC, TLP, PQS and CODDTest appear as the local-DBMS oracles the distributed setting is contrasted with. Written by claude-opus-5 from the 18 places this paper refers to SQLancer. See the evidence.

    Query Plan Guidance (QPG)
    We compare DistSQL against SOTA database and distributed system testing tools, including Squirrel [ 65], QPG [ 2], and EET [ 24], as well as distributed system testing tools, including Jepsen [20] and Mallory [36]. — source
    4 Comparison We evaluate five open-source distributed DBMSs (Table 3) using four existing tools: Jepsen [ 20], Mallory [36], QPG [2], and EET [24], and compare their performance with DistSQL. — source
  • VIREO: Human-in-the-Loop DBMS Fuzzing with Visualization and LLM Support (2026) · IEEE International Conference on Data Engineering
    SQLancer is one of four baselines, named among the state-of-the-art DBMS fuzzers VIREO measures against, and run with its default PQS oracle since the comparison is about crashes rather than logic bugs. Results are reported across five systems in both branch coverage and unique bugs. The paper's diagnosis is specific: SQLancer generates queries from fixed grammar rules tied to its oracles, which bounds how deep its exploration goes, and it does not vary configuration options such as --skip-grant-tables, so a class of bugs stays out of reach. SQLancer's oracles are also cited as the generation-based line of work VIREO departs from. Written by claude-opus-5 from the 20 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)
    We tried our best to compare VIREO against state-of-the-art DBMS fuzzers, including SQLsmith [61], SQLancer [57], SQUIRREL [70], and LEGO [34]. — source
    Although SQLancer was designed for logic bugs, it can also expose crashes and is evaluated using its default PQS oracle [60]. — source
  • A Comprehensive Study of Bugs in Relational DBMS (2025) · IEEE Transactions on Software Engineering
    SQLancer is both the study's reference generator and the base of its proof-of-concept tool. The study repeatedly measures bug-triggering SQL against what SQLancer can generate -- it does not support partition-related syntax at all, and it lacks bias toward diverse data types or high-risk constructs such as nested casts. SQLT is then built as an extension of SQLancer, adding BIT and JSON support that SQLancer under-supported, and running NoREC and TLP as its oracles. The two are compared directly over 24 hours on MySQL and SQLite, where SQLT found 6 bugs to SQLancer's 4, including one in MySQL that SQLancer did not reach. Written by claude-opus-5 from the 17 places this paper refers to SQLancer. See the evidence.
    We’ve also compared SQLT with SQLancer on the latest version of MySQL and SQLite (MySQL 8. — source
    SQLT detects 6 bugs and SQLancer detects 4 bugs. — source
    Also: uses infrastructure.
  • ARG: Testing Query Rewriters via Abstract Rule Guided Fuzzing (2025) · International Conference on Automated Software Engineering
    ARG integrates SQLancer to construct dynamic database schemas and populate them, and then measures itself against it, reporting 1017% more rewrite rules triggered and 15 more bugs in 24 hours. Written by claude-opus-5 from the 21 places this paper refers to SQLancer. See the evidence.
    In 24 hours, ARG triggered 76% and 1017% more written rules, triggered 13 and 15 more bugs than SQLsmith and SQLancer, respectively. — source
    In 24 hour experiment on these query rewriters, ARG triggered 76% and 1017% more written rules, triggered 13 and 15 more bugs than SQLsmith and SQLancer, respectively, In summary, we make the following contributions: •We observe that while query rewriters are widely used in DBMSs, bugs persist and can cause serious issues, yet effective testing tools remain lacking. — source
    Also: uses infrastructure.
  • Automated Discovery of Test Oracles for Database Management Systems Using LLMs (2025) · Proceedings of the ACM on Management of Data
    Argus uses SQLancer++'s query generator to produce seed queries while deliberately not using its predefined oracles, since discovering oracles is the paper's own subject. It measures itself against SQLancer, SQLancer++ and EET on coverage, and calls SQLancer a state-of-the-art open-source DBMS testing framework. Its artifact carries SQLancer's own source files. Written by claude-opus-5 from the 59 places this paper refers to SQLancer. See the evidence.
    2 Code Coverage We comparedArguswith three DBMS logic bugs finding tools, SQLancer [ 3,47–49,74], SQLancer++ [ 82] and EET [ 24] in multiple coverage metrics. — source
    1% higher line and branch coverage than SQLancer++, respectively, and 11. — source
    Also: uses infrastructure.
  • Checking Observational Correctness of Database Systems (2025) · Proc. ACM Program. Lang.
    SQLancer supplies the evaluation's yardstick: Troubadour is shown to verify that a trace exhibits none of the classes of bug SQLancer detects for the SQL fragment it supports, and was run on the queries and incorrect responses SQLancer had observed, reporting errors for all of them. The paper is careful that testing tools like SQLancer detect bugs but cannot verify observational correctness. Written by claude-opus-5 from the 6 places this paper refers to SQLancer. See the evidence.
    Troubadour can verify that a trace does not demonstrate any of the classes of bugs detected by DBMS fuzzer SQLancer for the fragment of SQL that Troubadour supports as well as detect the presence of such bugs. — source
    We also ran the tool on the query and the original incorrect response observed by SQLancer, and Troubadour reported errors for all the examples in under a second total as well, demonstrating its ability to detect semantic bugs. — source
  • Coni: Detecting Database Connector Bugs via State-Aware Test Case Generation (2025) · International Conference on Software Engineering
    SQLancer is both the motivating example and a baseline the authors had to build. The paper notes that SQLancer relies on JDBC solely to execute queries and retrieve results, without touching configuration properties or batch execution, which is the gap Coni targets. To measure against it the authors implemented SQLANCER+, adapting the connector and collecting results across connectors to find inconsistencies. It covered 5950 fewer branches than Coni and found none of the 21 bugs -- and the paper explains precisely why, giving a bug that requires calling setFetchSize, a method SQLANCER+ never calls. Written by claude-opus-5 from the 12 places this paper refers to SQLancer. See the evidence.
    We implemented SQLANCER+ by adapting the target database connector and collecting results from different connectors to identify inconsistencies. — source
    The result shows that CONI covered 5950, 6608, and 6587 more branches than SQLANCER+, RANDOOP, and EVOSUITE respectively. — source
  • DepState: Detecting Synchronization Failure Bugs in Distributed Database Management Systems (2025) · Proc. ACM Softw. Eng.
    SQLancer is one of five baselines and is called a state-of-the-art DBMS testing technique. Because it was built for single-node systems, the authors ran it against one SQL server of each cluster. The comparison is reported in both bugs and coverage of synchronization-related functions, and the paper's explanation for the gap is structural rather than dismissive: SQLancer, SQLsmith and Mozi only generate SQL queries, which cannot navigate the space of cluster states, so all three of SQLancer's bugs were ordinary ones and none was a synchronization failure. Written by claude-opus-5 from the 17 places this paper refers to SQLancer. See the evidence.
    To evaluate the effectiveness of DepState in testing DDBMSs, we compare it with five state-of-the-art tools: Jepsen [ 17],Mallory [26], SQLsmith [ 2], SQLancer [ 33], andMozi [23]. — source
    Number of Unique Bugs Detected by Jepsen, Mallory, SQLsmith, SQLancer, Mozi, and DepState DDBMS Jepsen Mallory SQLsmith SQLancer Mozi DepState MySQL NDB Cluster 0 1 0 1 7 7 MySQL InnoDB Cluster 1 0 0 1 6 2 MariaDB Galera Cluster 1 1 0 1 0 2 TiDB Cluster 0 0 0 0 0 3 Total (Sync Failure Bugs) 2 (0) 2 (0) 0 (0) 3 (0) 13 (0) 14 (14) 24 hours, recording the number of detected bugs and covered synchr... — source
  • Detecting DBMS bugs with context-sensitive instantiation and multi-plan execution (2025) · Computers & Security
    Kangaroo argues that SQLancer's oracles constrain the SQL they can test -- NoREC needing a WHERE clause, all three putting limits on queries -- and positions multi-plan execution as free of that constraint. SQLancer is then one of three tools it is measured against over 24 hours, run with NoREC, or TLP where NoREC is unavailable. Written by claude-opus-5 from the 36 places this paper refers to SQLancer. See the evidence.

    Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    We also compared Kangaroo with leading DBMS testing tools, such as Squirrel, SQLancer, and SQLRight. — source
    Specifically, after conducting a 24-hour test on the three DBMSs, Kangaroo successfully detected 17 bugs, while SQLancer, Squirrel, and SQLRight only identified 1, 3, and 6 bugs, respectively. — source
  • Detecting Logic Bugs in DBMSs via Equivalent Data Construction (2025) · Proc. ACM Manag. Data
    TLP is one of EDC's three baselines, named as a state-of-the-art open-source tool for finding logic bugs alongside EET and Radar. The comparison is reported in detail and is unusually candid about where each wins: EDC found 38 bugs to TLP's 9, they overlap on 3 -- all SQL-function bugs -- and the 6 bugs only TLP found involve JOINs, which are outside EDC's scope because it tests single-table queries. NoREC, TLP and PQS are each also described in the related-work section as the query-level approaches EDC is positioned against. Written by claude-opus-5 from the 21 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    We compare EDCagainst 3 state-of-the-art open-source tools for finding logic bugs in DBMSs: TLP [ 37], EET [ 27], and Radar [ 45]. — source
    During the evaluation,EDCfound 8, 6, 6, 2, 5, 6, and 7 bugs in MySQL, MariaDB, Percona, PostgreSQL, TiDB, OceanBase, and ClickHouse, respectively, while TLP detected 3 bugs in MySQL, 2 in Percona, 4 in TiDB, and none in others. — source
  • Hulk: Exploring Data-Sensitive Performance Anomalies in DBMSs via Data-Driven Analysis (2025) · Proc. ACM Softw. Eng.
    CERT is the closest prior work and the baseline, and the paper notes it is implemented in SQLancer, referring to it throughout as SQLancer-CERT -- one of only two open-source tools available for the comparison. SQLancer's own oracles are described in related work as the logic-bug counterpart to Hulk's performance focus. Written by claude-opus-5 from the 10 places this paper refers to SQLancer. See the evidence.

    Cardinality Estimation Restriction Testing (CERT)
    In addition, we compare Hulk with the state-of-the-art DBMS validation tools in industry, including both DBMS performance testing tool APOLLO [ 30] and SQLancer𝐶𝐸𝑅𝑇[11], as well as DBMS fuzzing tools Sqirrel [60]. — source
    Since only APOLLO [30] and SQLancer𝐶𝐸𝑅𝑇[11] are open-source tools, as a remedy, we still compared Hulk with other state-of-the-art SQL fuzzer ( Sqirrel [60]) to evaluate the capability to explore the state space on DBMSs. — source
  • PUPPY: Finding Performance Degradation Bugs in DBMSs via Limited-Optimization Plan Construction (2025) · International Conference on Software Engineering
    SQLancer is one of three widely used tools PUPPY is measured against over 48 hours, finding 6 bugs to PUPPY's 35. Query plan guidance is discussed as the closest prior idea, with PUPPY arguing that the sequence of optimisation operations inside a plan is a finer-grained signal than the plan itself. Written by claude-opus-5 from the 9 places this paper refers to SQLancer. See the evidence.

    Query Plan Guidance (QPG)
    To further evaluate the performance of PUPPY, we also compare PUPPY with SQLancer, SQLsmith, and SQUIRREL, which are widely used in industry. — source
    It shows that PUPPY outperforms SQLancer and SQLsmith in detecting bugs. — source
  • Reproducibility Report for ACM SIGMOD 2025 Paper: 'Constant Optimization Driven Database System Testing' (2025)
    This paper is a reproduction of SQLancer work rather than a citation of it. CODDTest is implemented inside SQLancer -- the report states the tool works by integrating the method with SQLancer, and that the SQLancer repository acknowledges the work as a supported testing method -- so reproducing it meant running a version of SQLancer that supports the method, from the authors' artifacts. The comparison it verifies is between three oracles in that one tool: CODDTest, NoREC and query partitioning, all executed through SQLancer against SQLite. Written by claude-opus-5 from the 13 places this paper refers to SQLancer. See the evidence.

    Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    We ran the scripts for CODDTest (the author’s method), NoREC and Query Partitioning. — source
    •CODDTest reported 1297 bugs, NoRec reported 644 bugs, and query partitioning generated 8280 database logs. — source
    Also: uses infrastructure.
  • Sembug: Detecting Logic Bugs in Dbms Through Generating Semantic-Aware Non-Optimizing Query (2025) · IEEE International Conference on Program Comprehension
    SemBug is a direct descendant of NoREC: it says it transforms the optimized query into a less optimized one 'inspired by NoREC', and its evaluation treats NoREC, TLP and Pinolo as the state-of-the-art techniques to beat. It also runs on SQLancer's own machinery, using it as the query generator, and its artifact carries SQLancer's source under a renamed package. Written by claude-opus-5 from the 84 places this paper refers to SQLancer. See the evidence.

    Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    3)Baselines: We compare SemBug against the state-ofthe-art logic bug detection techniques, namely NoREC [18], TLP [10], and Pinolo [19], respectively. — source
    Specifically, NoREC, TLP, and SemBug employ SQLancer [29] as the query generator, while Pinolo uses Go-Randgen [30]. — source
    Also: uses infrastructure, extends technique.
  • SQLaw: Detecting Bugs in GPU Database Management Systems via Rule-Based Differential Execution (2025) · IEEE Transactions on Software Engineering
    SQLaw imitates SQLancer's statement-level, syntax-based reduction to simplify its own bug reports, and takes NoREC and TLP as two of its three baselines, describing them as representative state-of-the-art approaches that have each found over a hundred bugs in non-GPU DBMSs. Written by claude-opus-5 from the 23 places this paper refers to SQLancer. See the evidence.

    Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    We selected three representative state-ofthe-art approaches, including SQLsmith ,NoREC and TLP . — source
    •NoREC [52] translates query statements into nonoptimized queries in the optimizer and compares the results to identify logic bugs. — source
  • SRS: Detecting Logic Bugs of Join Implementation in DBMSs via Set Relation Synthesis (2025) · Proc. ACM Manag. Data
    SRS is implemented on SQLancer, generating its database state with SQLancer's syntax-rule-based random generation and keeping SQLancer's query generation strategy for features outside the join. SQLancer's oracles are then also its baselines: PQS, NoREC, TLP and DQP are four of the six approaches it is measured against, and it reports finding 9 to 12 more bugs than each. Written by claude-opus-5 from the 59 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)Differential Query Plans (DQP)
    We selected six state-of-the-art approaches for comparison: PQS [ 25], TLP [ 24], NoREC [ 23], Pinolo [ 11], EET [ 13], and DQP [ 3]. — source
    As such, we include a comparison with NoREC in our evaluation. — source
    Also: uses infrastructure.
  • Testing Graph Databases with Synthesized Queries (2025) · Proc. ACM Manag. Data
    TLP reaches this paper through GDBMeter, which the authors describe as adopting the metamorphic oracles from TLP, originally designed for SQL, and partitioning queries using three-valued logic. That inheritance is the limitation they identify: a three-valued oracle applies only to filter clauses such as WHERE, and they show a case where all three of GDBMeter's partitioned queries return empty results and so reveal nothing. GDBMeter is one of four metamorphic detectors compared against. PQS is discussed as the closest relational analogue -- it also synthesises queries -- but is distinguished on the grounds that it relies on a subset relationship rather than establishing ground truth. Written by claude-opus-5 from the 16 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    •The metamorphic bug detectors, GDBMeter [ 22], Gamera [ 62], GQT [ 19], and GRev [ 33], each applying specifically designed query rewrite rules to identify discrepancies between the result of the original query and that of the rewritten query. — source
    Upon applying GDBMeter’s ternary logic partitioning [ 22] to the test query, all three partitioned queries (lines 5–13) also produce empty results. — source
  • Thanos: DBMS Bug Detection via Storage Engine Rotation Based Differential Testing (2025) · International Conference on Software Engineering
    SQLancer is one of Thanos's three baselines and is named a state-of-the-art DBMS testing tool throughout. The comparison is reported per system in both bugs and branch coverage, and SQLancer found none of the 14 bugs Thanos did. The paper's argument for why is about where the oracles apply: SQLancer's rely on specially crafted rules -- NoREC on optimizer behaviour, and it describes TLP as needing a pivot row -- which leaves storage-engine differences outside their reach, and its use of standard SQL syntax bounds the code it exercises. SQLancer's construction of functionally equivalent queries is also cited as the metamorphic-testing line Thanos departs from. Written by claude-opus-5 from the 20 places this paper refers to SQLancer. See the evidence.

    Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    Comparison with Existing Techniques To assess the effectiveness of THANOS, we conducted a comparative study that pitted THANOS against contemporary state-of-the-art DBMS testing methods, namely SQLancer, SQLsmith, and SQUIRREL. — source
    DBMS SQLancer SQLsmith SQUIRREL THANOS MySQL 0 1 1 6 MariaDB 0 0 1 5 Percona 0 0 1 3 Total 0 1 3 14 Increment 14↑ 13↑ 11↑ – TABLE IV: Number of branches covered by THANOS, SQLancer, SQLsmith, and SQUIRREL on 3 DBMSs in 24 hours. — source
  • TSGuard: Detecting Logic Bugs in Time Series Management Systems Via Time Series Algebra (2025) · IEEE International Conference on Software Maintenance and Evolution
    SQLancer is TSGuard's baseline, and the paper is explicit about the form that takes: it adapted SQLancer, an open-source relational database testing tool, as a baseline for comparison. The two were run for 7200 seconds against the same three systems, with TSGuard finding 38 bugs to SQLancer's 7 and generating several times more valid queries. NoREC, TLP, PQS and QPG are each described in the discussion of metamorphic testing's limits, which is where the paper argues that oracles built for relational queries do not transfer to time-series ones. The adaptation is what made a relational tool runnable on these systems for the comparison, not a contribution TSGuard claims. Written by claude-opus-5 from the 18 places this paper refers to SQLancer. See the evidence.
    Comparison with Other Techniques To evaluate the effectiveness of TSGuard in detecting logic bugs in TSMSs, we adapted the open-source relational database testing tool SQLancer as a baseline for comparison. — source
    MetricsSQLancer TSGuard InfluxDB IotDB TDengine InfluxDB IotDB TDengine Bugs 2 2 3 12 9 17 Sequences 3805 42653 118889 178232 413218 222726 Valid Queries23243 114024 95007 196583 447972 264704 Invalid Queries376 27401 132957 1905 48253 11502 Table V presents the results from the 7200-second experiment, comparing TSGuard and SQLancer in terms of bug detection, syntax node sequence generation, an... — source
  • Understanding and Detecting SQL Function Bugs: Using Simple Boundary Arguments to Trigger Hundreds of DBMS Bugs (2025) · European Conference on Computer Systems
    SQLancer is one of three baselines, described as a state-of-the-art DBMS testing tool widely used in industry, and run in PQS mode with default settings. The result is stark and reported twice: over 24 hours SQLancer found no SQL function bugs at all, against Soft's 2,956, and Soft covered many times more branches in the function components. The paper's explanation is concrete rather than dismissive -- supporting a new function in SQLancer means writing a function model in Java, and it only generates random values for function arguments, so the boundary values these bugs need are not something it produces. Written by claude-opus-5 from the 15 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)
    We also used the latest versions of Sqirrel [63], SQLsmith [ 53], and SQLancer in PQS mode [ 51] with their default configurations to test these DBMSs, but they did not find any SQL function bugs. — source
    5 Comparison with Other Testing Works To demonstrate the effectiveness of our methods, we compared Soft against three state-of-the-art DBMS testing tools, namely Sqirrel, SQLancer, and SQLsmith, which are widely used in the industry. — source
  • Unveiling Logic Bugs in SPJG Query Optimizations within DBMS (2025) · ACM Transactions on Database Systems
    SQLancer is the paper's reference point and its baseline: four of SQLancer's methods -- PQS, TLP, NoREC and DQP -- are the four baselines TQS is measured against, and the paper calls SQLancer the state-of-the-art approach for detecting logic bugs while arguing it is not designed for multi-table queries. Written by claude-opus-5 from the 38 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)Ternary Logic Partitioning (TLP)Non-optimizing Reference Engine Construction (NoREC)Differential Query Plans (DQP)
    We compare TQS with SQLancer,3which is the state-of-the-art approach to detecting logic bugs in databases. — source
    We use four methods in SQLancer as our baselines. — source
  • DBStorm: Generating Various Effective Workloads for Testing Isolation Levels (2024) · International Symposium on Software Testing and Analysis
    SQLancer supplies DBStorm's SQL. The paper states that because SQLancer targets the relational model it is used to generate syntactically and semantically correct SQL operations, and that since SQLancer mainly produces serially executed operations they revised it to generate parallel ones. It is also one of the tools measured against, and the comparison makes the paper's point precisely: SQLsmith, SQLancer and Squirrel between them reveal 760 bugs of which none is an isolation bug, because they execute transactions sequentially in a single thread and so cannot produce a cycle in the conflict graph at all. Written by claude-opus-5 from the 17 places this paper refers to SQLancer. See the evidence.
    SQLancer [60] and TQS [67] randomly generate queries and provide a test oracle to identify logical bugs. — source
    SQLancer ,Squrriel and SQLsmith sequentially execute transactions in a single thread, so it is impossible to exist a cycle in the conflict graph and we do not put them in Fig. — source
    Also: uses infrastructure.
  • Differential Optimization Testing of Gremlin-Based Graph Database Systems (2024) · International Conference on Information Control Systems & Technologies
    SQLancer's techniques frame the paper twice over. NoREC is the direct inspiration and the direct obstacle: DOT targets the same class of optimisation bugs, but the paper explains at length why NoREC's rewriting cannot be applied to Gremlin's procedural queries, which is what forces the different mechanism. Query partitioning is the comparison, reached through GDBMeter, one of four existing approaches for finding logic bugs in graph databases; the paper compares DOT with differential testing and with query partitioning as the two families that can find these bugs. Written by claude-opus-5 from the 17 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    Comparison with Existing Approaches To the best of our knowledge, four existing approaches [13]– [16] can detect logic bugs in GDBs. — source
    Therefore, we compare DOT with differential testing and query partitioning. — source
  • Dinkel: State-Aware and Granular Framework for Validating Graph Databases (2024) · Proceedings of the VLDB Endowment
    SQLancer's techniques appear as the relational background against which graph testing is measured. GDBMeter is one of the existing approaches Dinkel is compared with, and the paper identifies its oracle as query partitioning -- decomposing a query's predicate and checking the decomposed queries agree with the original. PQS is cited as the relational counterpart that synthesises queries fetching specific rows. The paper's own contribution is generation rather than an oracle, and it observes that relational testing is the more mature field, with both query generation and test-oracle construction well researched there. Written by claude-opus-5 from the 16 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    As shown in Table 4, Dinkel supports more Cypher clauses than existing approaches [ 13,14,20,27,51]. — source
    This comparison is reasonable and objective because: (1) none of the bugs found by Dinkel are marked as duplicated by developers, meaning that no approach found these bugs until Dinkel found them; and (2) all existing approaches have extensively tested Neo4j and RedisGraph [ 13,14,20,27,51], meaning that in these two GDBMSs, no approach found the long-latent bugs found by Dinkel during their ev... — source
  • Mozi: Discovering DBMS Bugs via Configuration-Based Equivalent Transformation (2024) · International Conference on Software Engineering
    SQLancer's three oracles are the point of contrast and the baseline: Mozi argues that TLP applies only to queries using particular clauses and that NoREC's equivalent-query construction is limited by how well SQL semantics can be modelled, then runs PQS, NoREC and TLP against itself and reports 21 to 25 more bugs than each. Written by claude-opus-5 from the 24 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    We also used SQLancer [ 45] (with test oracles PQS [ 48], TLP [ 47], and NoREC [ 46]), Apollo [25], and Amoeba [33] to test these DBMSs, but they can only find a subset of these bugs (shown in Section 5. — source
    Specifically, we compared Mozi𝑐𝑜𝑟against SQLancer using three logic test oracles, namely PQS [ 48], NoREC [ 46], and TLP [ 47] for correctness bug detection. — source
  • NNTailor: A Neural Network-Driven Fuzzer for DataBase Management Systems (2024) · IEEE International Conference on Tools with Artificial Intelligence
    SQLancer is one of NNTailor's two baselines, compared on code coverage and on the syntactic and semantic correctness of generated queries. The paper attributes SQLancer's coverage ceiling to template reliance -- predefined rules achieve considerable coverage but bound how much of the code space can be explored -- while acknowledging the other side of that trade: because SQLancer's oracles require expressions built to predefined semantic rules, it achieves high semantic correctness on SQLite. The comparison is reported as mixed rather than one-sided, with the paper noting that the two tools have their own advantages on different systems. Written by claude-opus-5 from the 15 places this paper refers to SQLancer. See the evidence.
    We conducted evaluations of NNTailor on the latest versions of PostgreSQL and SQLite, comparing its performance with SQLsmith[5] and SQLancer[6, 25, 26, 27]. — source
    With the neural network model-driven mutation approach, NNTailor achieves 35% and 10% higher code line coverage compared to SQLsmith and SQLancer. — source
  • Semantic Conformance Testing of Relational DBMS (2024) · Proceedings of the VLDB Endowment
    SEMCONT is built on SQLancer, whose syntax-guided generation it enhances with coverage guidance and uses as the seed pool for its own query generation. TLP and NoREC are then its baselines, described as state-of-the-art metamorphic testing methods and run in both their SQLancer and SQLRight implementations. Written by claude-opus-5 from the 42 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)Non-optimizing Reference Engine Construction (NoREC)
    We compared SEMCONT with TLP [41] and NoREC [40], which are state-of-the-art metamorphic testing methods for testing RDBMS. — source
    Both NoREC and TLP are implemented in SQLancer [14] and SQLRight [34]. — source
    Also: uses infrastructure.
  • SQLPass: A Semantic Effective Fuzzing Method for DBMS (2024) · Annual International Computer Software and Applications Conference
    SQLancer is one of four baselines, compared on semantic correctness, line coverage and bug replication speed. The paper's account of it is two-sided: because SQLancer is generation-based it cannot replicate existing bugs from seed test cases, which is one of the three measures; but it also observes that although SQLancer generates a limited range of SQL test cases, their syntactic and semantic accuracy is high, so it reaches deeper code logic and achieves higher coverage than the tools whose generated statements are less well formed. PQS's pivot-row construction is named as the reason for that accuracy. Written by claude-opus-5 from the 12 places this paper refers to SQLancer. See the evidence.
    b) C omparison with benchmark testing tools: We conduct 24 hours experiments on SQLPass and benchmark testing tools AFL, SQLsmith, SQLancer, and Squirrel on SQLite, MySQL, MariaDB, and PostgreSQL, respectively, and compare and evaluate three ind icators: semantic correctness, code (line) coverage, and bug replication speed. — source
    Therefore, the code coverage generated by the SQL test cases it generates is also not high; Although SQLancer generates limited types of SQL test cases, the syntax and semantic accuracy of the generated SQL statements are high, so it can trigger deeper code logic and generate higher code coverage; The syntax and semantic accuracy of SQL test cases generated by Squirrel mutation are not high, bu... — source
  • Testing Graph Database Systems via Equivalent Query Rewriting (2024) · International Conference on Software Engineering
    The paper works from Ternary Logic Partitioning throughout, but at one remove: its comparison target is GDBMeter, which carries TLP to graph databases, and the paper is precise that GDBMeter is based on Query Partitioning and reuses a test oracle designed for relational systems. That reuse is its critique -- it reports that none of the graph-related bugs were detected by GDBMeter for exactly that reason, that TLP applies only to filter clauses, and that partitioning yields four distinct query plans against GRev's many. It states outright that GRev cannot be compared with relational tools such as SQLancer, so SQLancer itself is not a baseline; TLP is, through GDBMeter. Written by claude-opus-5 from the 20 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    , GDsmith [ 13], Grand [ 44], and GDBMeter [ 15]). — source
    , GDsmith [ 13], Grand [ 44], and GDBMeter [ 15], that can detect bugs other than crashes. — source
  • Testing Gremlin-Based Graph Database Systems via Query Disassembling (2024) · International Symposium on Software Testing and Analysis
    Query partitioning is the technique QuDi positions itself against, reached through GDBMeter, which the paper describes as adopting TLP to derive a graph query into three disjoint sub-queries and so focusing on predicate-related bugs. The comparison is run: the authors check whether GDBMeter's query partitioning can detect the 25 bugs QuDi found. The conclusion is complementarity rather than replacement -- query partitioning cannot stop the system's optimisations from kicking in and so cannot expose assembly issues, and the paper says the two are complementary. SQLancer itself is explicitly not compared against, since QuDi targets Gremlin and SQLancer targets SQL. Written by claude-opus-5 from the 18 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    ,Grand[ 64],GDsmith[ 39],RD2[62], and GDBMeter [ 42], can /f_ind bugs in GDBs. — source
    Comparison with query partitioning. — source
  • Towards Generic Database Management System Fuzzing (2024) · USENIX Security Symposium
    SQLancer is one of BuzzBee's baselines for the relational case, run with its PQS oracle, and also on ArangoDB because SQLancer had recently added support for it. The comparison is reported per bug: on several Redis and RedisGraph defects SQLancer's column is empty, and the paper attributes that to scope -- it looks for logic errors through specific syntax structures rather than the crashes and semantic faults those systems exhibit. The paper is even-handed about the relational case, noting that none of BuzzBee, SQUIRREL or SQLancer found a bug in current PostgreSQL within 24 hours. SQLancer's design also informs BuzzBee indirectly through the IR line of work it belongs to. Written by claude-opus-5 from the 21 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)
    We compare BUZZBEEwith general-purpose fuzzers AFL++ [ 14],REDQUEEN [4], syntax-aware fuzzers POLYGLOT [9], Grammarinator [ 22], and SQL-specialized SQUIR REL [56] and SQLANCER [43]. — source
    For relational DBMSs, we compare BUZZBEEwith SQUIRREL [56] and SQL ANCER (PQS [ 43]), two DBMS fuzzers specialized in SQL DBMS fuzzing. — source
  • WingFuzz: Implementing Continuous Fuzzing for DBMSs (2024) · USENIX Annual Technical Conference
    SQLancer is one of three state-of-the-art fuzzers WingFuzz is measured against, with branch counts and bug counts reported per DBMS -- 211,620 more branches and 25 more unique bugs. The paper attributes SQLancer's lower coverage to its generating queries from custom pattern rules tied to the grammar its oracles need, and describes its three oracles, noting NoREC requires a query with WHERE and JOIN clauses. Written by claude-opus-5 from the 11 places this paper refers to SQLancer. See the evidence.
    1 Compared with Existing Fuzzers To show the effectiveness of WINGFUZZ, we compared it with three state-of-the-art fuzzers, including conventional mutation-based fuzzer SQUIRREL as well as generated-based fuzzer SQLancer and SQLsmith, which are widely used in the industry to test DBMSs. — source
    They show that WINGFUZZ covers a total of 211620, 197059, 132397 more branches than SQLancer, SQLsmith, and SQUIRREL, respectively. — source
  • Detecting Isolation Bugs via Transaction Oracle Construction (2023) · International Conference on Software Engineering
    SQLancer supplies Troc's generation and defines the gap Troc fills. The paper states that Troc's database and SQL statement generation is mainly based on SQLancer, and that the schema features it works with -- primary keys, indexes, data types and conditions -- are those SQLancer supports. SQLancer is also among the tools measured against, where the paper's point is structural: it and SQLsmith cannot generate transaction test cases and have no oracle for them, so isolation bugs are outside their reach entirely. PQS, TLP, NoREC and QPG are described as the single-query oracles this work is positioned beyond. Written by claude-opus-5 from the 12 places this paper refers to SQLancer. See the evidence.
    , SQLsmith [24], SQLancer [26]–[28], Elle [23] and Cobra [22]. — source
    , SQLsmith [24] and SQLancer [26]–[28], cannot generate transaction test cases, and do not have a test oracle for transaction test cases. — source
    Also: uses infrastructure.
  • Detecting Logic Bugs of Join Optimizations in DBMS (2023) · Proc. ACM Manag. Data
    SQLancer is the work TQS is built against and the paper says so directly, calling it the current state-of-the-art tool for finding logic bugs in DBMSs and the most closely related work to its own. All three of its oracles serve as baselines -- PQS, TLP and NoREC -- and the paper is careful about the comparison's mechanics, noting that SQLancer supports different oracles on different systems and that its generated joins often return empty results and so cannot be used for testing. The gap TQS identifies is single-table scope: SQLancer is not designed to test multi-table queries, which is exactly where join-optimisation bugs live. Written by claude-opus-5 from the 20 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)Ternary Logic Partitioning (TLP)Non-optimizing Reference Engine Construction (NoREC)
    We use three methods in SQLancer as our baselines. — source
    Note that due to the compatibility problem, SQLancer implements different approaches on different databases (PQS and TLP on MySQL and X-DB; NoRec on MariaDB; TLP on TiDB). — source
  • Pinolo: Detecting Logical Bugs in Database Management Systems with Approximate Query Synthesis (2023) · USENIX Annual Technical Conference
    Pinolo positions itself directly against SQLancer's oracles: PQS is the oracle-guided synthesis it says considers only one row at a time, NoREC and TLP are the metamorphic approaches it says preserve too much of the query, and it states that metamorphic testing of that kind is recognised as the state of the art in DBMS logical bug detection. Written by claude-opus-5 from the 35 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    For example, the logical bug shown in Figure 1 can not be revealed by NOREC [34] and TLP [35], as the transformations preserve all the operators and the functions, still triggering the buggy evaluation process. — source
    Compared with the existing techniques [ 34–36],PINOLO considers more SQL features, such as set operators, arithmetic expressions, sub-queries, etc. — source
  • Sequence-Oriented DBMS Fuzzing (2023) · IEEE International Conference on Data Engineering
    SQLancer is one of the three fuzzers Lego is measured against, described as a state-of-the-art academic fuzzer that generates from custom rules mainly for SELECT statements. Lego reports covering 198% more branches than it, and notes that SQLancer found no bugs in their setting. Written by claude-opus-5 from the 26 places this paper refers to SQLancer. See the evidence.
    We evaluate LEGO on PostgreSQL, MySQL, MariaDB, and Comdb2 against SQLancer, SQLsmith, and SQUIRREL. — source
    We evaluate LEGO on the latest version of PostgreSQL, MySQL, MariaDB, and Comdb2 against SQLancer, SQLsmith, and SQUIRREL. — source
  • Testing Database Systems via Differential Query Execution (2023) · International Conference on Software Engineering
    DQE is built on SQLancer. The paper states that its implementation is based on SQLancer and that its database generation is mainly adopted from it, and it notes that DQE, PQS, NoREC and TLP are all built on SQLancer and so share similar query generation -- offered as the explanation for their comparable code coverage. PQS, NoREC and TLP are also its baselines: it reports coverage and bug counts against all three, and its motivation is that none of them can be applied to UPDATE and DELETE statements, which is the gap DQE fills. Written by claude-opus-5 from the 21 places this paper refers to SQLancer. See the evidence.

    Pivoted Query Synthesis (PQS)Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    , PQS [9], NoREC [10] and TLP [11]) that aim to detect logic bugs in DBMSs. — source
    Thus, they cannot detect 18 logic bugs related to this kind of errors TABLE VCOVERAGE INFORMATION Tool MySQL MariaDB PQS 19 NoREC-18 TLP 18 DQE 15 21 in SELECT queries. — source
    Also: uses infrastructure.
  • Automatic Detection of Performance Bugs in Database Systems using Equivalent Queries (2022) · International Conference on Software Engineering
    TLP is one of AMOEBA's three baselines and the paper calls it the state-of-the-art tool for finding logic bugs in DBMSs using metamorphic testing. Because TLP also produces equivalent queries, it can be repurposed as a source of pairs, and the authors built a baseline of 2000 TLP-generated pairs to test that. The finding is a clean negative result about transfer: TLP's mutation rules were not designed for performance, and its mutant queries are on average 17 times slower than their base query, so that inherent overhead swamps the signal a performance oracle depends on. AMOEBA found 25 and 14 bugs against the TLP benchmark's 1 and 1. Written by claude-opus-5 from the 15 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    We also compared AMOEBA against two other sources of equivalent queries that could be used for detecting performance bugs: a manually-written test suite in a widely-used query optimization framework, and the Ternary Logic Partitioning (TLP) approach [ 38]. — source
    To answer Q4, we compare AMOEBA to three baseline based on two of these existing approaches: Calcite [19, 48] and TLP [38]. — source
  • Detecting Logical Bugs of DBMS with Coverage-based Guidance (2022) · USENIX Security Symposium
    SQLRight is built on SQLancer and Squirrel, and two of its four oracles -- NoREC and TLP -- are ported from SQLancer directly. It then measures itself against SQLancer as the state-of-the-art oracle-based tool, reporting more bugs but acknowledging SQLancer's much higher query validity. Written by claude-opus-5 from the 83 places this paper refers to SQLancer. See the evidence.

    Non-optimizing Reference Engine Construction (NoREC)Ternary Logic Partitioning (TLP)
    We also compare our system with the stateof-the-art tools, including SQLancer (using oracles to detect logical bugs) and Squirrel (using code coverage to detect crashes and assertion failures). — source
    After testing for 72 hours, SQLRight reports 12 unique logical bugs, Squirrel detects one bug, and SQLancer does not find any bug. — source
    Also: uses infrastructure, extends technique.
  • Griffin : Grammar-Free DBMS Fuzzing (2022) · International Conference on Automated Software Engineering
    SQLancer is Griffin's baseline and its motivating example of the cost it avoids: the paper counts the lines of code SQLancer needs to support each DBMS -- over 8,000 for PostgreSQL -- as the adaptation burden a grammar-free approach removes, and reports finding 27 more bugs than SQLancer in 12 hours. Written by claude-opus-5 from the 23 places this paper refers to SQLancer. See the evidence.
    11% more branches, and finds 27, 27, and 22 more bugs in 12 hours than SQLancer, SQLsmith, and Sqirrel, respectively. — source
    11% more branches, and finds 27, 27, and 22 more bugs in 12 hours than SQLancer, SQLsmith, and Sqirrel, respectively. — source
  • Unicorn: detect runtime errors in time-series databases with hybrid input synthesis (2022) · International Symposium on Software Testing and Analysis
    SQLancer is Unicorn's principal baseline. The authors adapted it to each of the six time-series systems and report coverage and bug counts side by side across the whole evaluation, and they call it a state-of-the-art database fuzzer when introducing that comparison. Their explanation for the gap is about scope rather than quality: SQLancer targets the relational model, so its generated queries lack time-series elements and most are invalid on these systems, and it cannot address KairosDB at all because that system takes JSON over HTTP rather than SQL. They also cite SQLancer's three test oracles as the prior work on oracle design. Written by claude-opus-5 from the 26 places this paper refers to SQLancer. See the evidence.
    We also adapted the industrial fuzzers SQLancer [ 25] and SQLsmith [ 31] for comparison. — source
    6 EVALUATION In this section, we evaluate the effectiveness of Unicorn in terms of coverage and bug discovery against state-of-the-art database fuzzers—SQLsmith and SQLancer. — source
  • Industry Practice of Coverage-Guided Enterprise-Level DBMS Fuzzing (2021) · 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)
    Compared to industrial black box fuzzers SQLsmith and SQLancer, as well as coverage-guided academic fuzzer Squirrel, RATEL covered 38. — source
    Compared to SQLsmith, SQLancer, and Squirrel, it covered 38. — source
  • Testing DBMS Performance with Mutations (2021) · arXiv (Cornell University)
    AMOEBA takes TLP as the closest related effort and argues it does not transfer: its equivalent queries are tailored to logic bugs and are comparatively simple, so they cannot serve as a metamorphic relation for performance. TLP is then one of the sources of equivalent queries AMOEBA is compared against. Written by claude-opus-5 from the 28 places this paper refers to SQLancer. See the evidence.

    Ternary Logic Partitioning (TLP)
    We compare AMOEBA against two other sources of equivalent queries that could be used for detecting performance bugs: (1) a manually-written test suite in a widely-used query optimization framework, and (2) the TLP. — source

Papers calling SQLancer state of the art (34)

These papers describe SQLancer or one of its techniques as the state of the art. That is a different claim from building on it, so it is counted separately and is not part of the 30 above. Quoted here are the 9 that make the claim on their own account rather than while listing the tools they measure against; the other 25 say it in the same sentence that names their comparison set.

All 34 papers calling SQLancer state of the art

All 209 papers citing SQLancer
Paper Year Relationships
A Comprehensive Survey on Database Management System Fuzzing: Techniques, Taxonomy and Evaluation 2026 citescompares
A Formal Framework for Typing and Cast Semantics in SQL Engines 2026 cites
A Framework for Systematic Analysis and Automated Detection of Dark Patterns on E-Commerce Websites 2026 cites
A Set-Theoretic Approach to Detecting Logic Bugs in DBMS Inner Join Optimizations 2026 citesuses or extendscompares
Agentic Proof and Property-Based Testing via Property-Templates in Data-Intensive Computing 2026 cites
An Automated Risk Scoring Framework for SQL Execution Plan Analysis and Performance Regression Detection in Oracle Database Systems 2026 cites
Aurora DSQL: Scalable, Multi-Region OLTP 2026 cites
Beacon: Detecting Broken Access Control Vulnerabilities in DBMSs via System Catalog Consistency Validation 2026 cites
Boosting DBMS Test Coverage via LLM-Driven SQL Generation 2026 cites
Bounded, Indeterminate, or a Bug: A Condition-Aware Oracle for Differential Testing of SQL Aggregates 2026 cites
BugForge: Constructing and Utilizing DBMS Bug Repository to Enhance DBMS Testing 2026 citescomparesstate of the art
Cloud Analytics Benchmarking: Where We Are, What Is Missing, and Where We Should Go 2026 cites
Code Generation by Differential Test Time Scaling 2026 cites
Computer-Orchestrated Design of Algorithms: From Join Specification to Implementation 2026 cites
DBcover: A White-box SQL Test Generation Framework for Coverage Improvement 2026 citescompares
DBugScribe: Automatic Database Bug Reproduction from Community Reports 2026 cites
Detecting Data-Type-Related Logic Bugs in Relational DBMSs via Compatible Database Construction 2026 cites
Detecting DBMS Bugs by Constructing Equivalent Representations of Intermediate Query Results 2026 citescomparesstate of the art
DIRT: Database-Integrated Random Testing 2026 citesuses or extendscomparesstate of the art
Effective Bug Detection in Graph Database Engines: An LLM-Based Approach 2026 cites
Efficiently Detecting DBMS Bugs through Bottom-up Syntax-based SQL Generation 2026 citescomparesstate of the art
Eidolon: Perform Noise-Aware Fuzzing on FHE Libraries via Equivalence Expression Transformation 2026 cites
EPSC: Testing Database Management Systems via Equivalent Prepared Statement Construction 2026 citesuses or extendscompares
EXPLAIN Yourself! Finding Query Planner Stalls Across DBMSes 2026 cites
Finding Missed Optimizations in DBMSs through Unbalanced Short-circuit Query Construction 2026 citescomparesstate of the art
Finding Performance Issues in Database Systems by Exploiting Dormant Code Paths 2026 citesuses or extendscompares
Fuzzing with Agents? Generators Are All You Need 2026 cites
FuzzySQL: Uncovering Hidden Vulnerabilities in DBMS Special Features with LLM-Driven Fuzzing 2026 citescomparesstate of the art
Graph-Aware Fuzzing for Graph Database Management Systems 2026 cites
Investigating Metamorphic Fuzz Oracle Enhancement via Large Language Models 2026 cites
LLM-Based Test Case Generation in DBMS through Monte Carlo Tree Search 2026 cites
LLMSQLMUTATOR: LLM-Powered Test Case Generation for Database Using Bug Reports 2026 citesuses or extendscomparesstate of the art
Logos: Certified Order-Sensitive SQL Rewrites with Mechanized Semantics and LLM Guidance 2026 cites
Metamorphic Testing for Infrastructure-as-Code Engines 2026 cites
One DBMS, Two Modes, and a Bunch of Bugs: Catching Logic Bugs in Distributed DBMSs via Differential Testing 2026 citescomparesstate of the art
Operationalizing Property-Based Testing for Data-Intensive Scalable Computing Systems 2026 citesstate of the art
Optimizing Database System Performance: Design and Query Optimization Strategies 2026 cites
Programmable Property-Based Testing 2026 cites
ReSequel: Robust LLM-assisted Query Rewriting and Optimization using Templatization and Sampling 2026 cites
SmartOracle - An Agentic Approach to Mitigate Noise in Differential Oracles 2026 cites
Testing Graph Databases via Transformations Between Fixed-Length and Variable-Length Queries 2026 cites
Towards the Systematic Testing of Regular Expression Engines 2026 cites
Understanding and Finding JIT Compiler Performance Bugs 2026 cites
Understanding Query Optimization Bugs in Graph Database Systems 2026 cites
VIREO: Human-in-the-Loop DBMS Fuzzing with Visualization and LLM Support 2026 citescomparesstate of the art
Why Property-Based Testing is Necessary for Data Intensive Scalable Computing 2026 cites
A Comparative Survey of Mutation Testing Across Large Language Models, REST APIs, and Database Engines 2025 cites
A Comprehensive Study of Bugs in Relational DBMS 2025 citesuses or extendscompares
Anomaly Pattern-guided Transaction Bug Testing in Relational Databases 2025 citesuses or extends
ARG: Testing Query Rewriters via Abstract Rule Guided Fuzzing 2025 citesuses or extendscompares
Arguzz: Testing zk VMs for Soundness and Completeness Bugs 2025 cites
AskDB: AI-Assisted Natural Language Interface for Database Querying and Visualization 2025 cites
Automated Discovery of Test Oracles for Database Management Systems Using LLMs 2025 citesuses or extendscomparesstate of the art
Checking Observational Correctness of Database Systems 2025 citescompares
Coni: Detecting Database Connector Bugs via State-Aware Test Case Generation 2025 citescompares
CypherFuzzer: A Tool for Testing Access Control in Graph Databases 2025 cites
DepState: Detecting Synchronization Failure Bugs in Distributed Database Management Systems 2025 citescomparesstate of the art
Detecting data manipulation errors in android applications using scene-guided exploration 2025 cites
Detecting DBMS bugs with context-sensitive instantiation and multi-plan execution 2025 citescomparesstate of the art
Detecting Isolation Anomalies in Relational DBMSs 2025 cites
Detecting Logic Bugs in DBMSs via Equivalent Data Construction 2025 citescomparesstate of the art
Detecting Schema-Related Logic Bugs in Relational DBMSs via Equivalent Database Construction 2025 cites
Diverse Database Replication Based on Snapshot Isolation – Performance Implications of Improved Dependability 2025 cites
Evaluating ERD Models and RAID-Based Storage for Query Performance Optimization in Relational Databases 2025 cites
Fawkes: Finding Data Durability Bugs in DBMSs via Recovered Data State Verification 2025 cites
Fucci: Database Transaction Fuzzing via Random Conflict Construction and Multilevel Constraint Solving 2025 citesuses or extends
Fuzz Testing for Database Management System Configuration Errors 2025 cites
Fuzzing Graph Database Applications with Graph Transformations 2025 cites
Ghosts in DBMS: Revealing the Security Impacts of Silent Fixes 2025 cites
Graphiti: Bridging Graph and Relational Database Queries 2025 cites
Hulk: Exploring Data-Sensitive Performance Anomalies in DBMSs via Data-Driven Analysis 2025 citescomparesstate of the art
Improving Multitasking DBMS Fuzzing With More Accurate Coverage and Testcase Trimming 2025 cites
Janus: Detecting Rendering Bugs in Web Browsers via Visual Delta Consistency 2025 cites
Language-Based Testing for Knowledge Graphs 2025 cites
LLM-Assisted Dialect-Agnostic SQL Query Parsing 2025 cites
LLM-based Dynamic Differential Testing for Database Connectors with Reinforcement Learning-Guided Prompt Selection 2025 cites
Locus: Agentic Predicate Synthesis for Directed Fuzzing 2025 cites
MTZK: Testing and Exploring Bugs in Zero-Knowledge (ZK) Compilers 2025 cites
Nabil: A Text-to-SQL Model Based on Brain-Inspired Computing Techniques and Large Language Modeling 2025 cites
OptionFuzz: The Fuzzer with Coverage-Guided Dynamic Configuration Scheduling 2025 cites
PANGOLIN: a Comprehensive Testing Framework for Configuration-Rich Key-Value Stores 2025 cites
Parser Knows Best: Testing DBMS with Coverage-Guided Grammar-Rule Traversal 2025 cites
PBench: Workload Synthesizer with Real Statistics for Cloud Analytics Benchmarking 2025 cites
PUPPY: Finding Performance Degradation Bugs in DBMSs via Limited-Optimization Plan Construction 2025 citescompares
QITE: Assembly-Level, Cross-Platform Testing of Quantum Computing Platforms 2025 cites
QOVIS: Understanding and Diagnosing Query Optimizer via a Visualization-assisted Approach (Revision) 2025 cites
QTRAN: Extending Metamorphic-Oracle Based Logical Bug Detection Techniques for Multiple-DBMS Dialect Support 2025 citesuses or extendsstate of the art
Real-World Scalability of PostgreSQL: Practical Techniques Use Case Study 2025 cites
Reproducibility Report for ACM SIGMOD 2025 Paper: 'Constant Optimization Driven Database System Testing' 2025 citesuses or extendscompares
Research on Coverage Statistics in Fuzz Testing of Closed-Source DBMS 2025 cites
Review of Fuzz Testing Techniques for Database Management Systems 2025 cites
ROSA: Finding Backdoors with Fuzzing 2025 cites
Semantic Hint-Based Fuzzing for Time-Series Databases 2025 citesstate of the art
Sembug: Detecting Logic Bugs in Dbms Through Generating Semantic-Aware Non-Optimizing Query 2025 citesuses or extendscomparesstate of the art
Siloso: Finding Logic Bugs in RDBMS via Dialect-Adaptable Reference Engine Construction 2025 cites
Simple Testing Can Expose Most Critical Transaction Bugs: Understanding and Detecting Write-Specific Serializability Violations in Database Systems 2025 citesuses or extends
SQLaser: Detecting database management system (DBMS) logic bugs with clause-guided fuzzing 2025 cites
SQLaw: Detecting Bugs in GPU Database Management Systems via Rule-Based Differential Execution 2025 citescomparesstate of the art
SQLBarber: A System Leveraging Large Language Models to Generate Customized and Realistic SQL Workloads 2025 cites
SQLStorm: Taking Database Benchmarking into the LLM Era 2025 cites
SRS: Detecting Logic Bugs of Join Implementation in DBMSs via Set Relation Synthesis 2025 citesuses or extendscomparesstate of the art
Systems Correctness Practices at Amazon Web Services 2025 cites
Test Data Generation for Complex SQL Queries 2025 cites
Testing Graph Databases with Synthesized Queries 2025 citescompares
Testing Spatial Database Engines via Spatial Equivalent Transformation 2025 cites
Thanos: DBMS Bug Detection via Storage Engine Rotation Based Differential Testing 2025 citescomparesstate of the art
Toward Understanding Bugs in Vector Database Management Systems 2025 cites
TSGuard: Detecting Logic Bugs in Time Series Management Systems Via Time Series Algebra 2025 citescompares
Understanding and Detecting SQL Function Bugs: Using Simple Boundary Arguments to Trigger Hundreds of DBMS Bugs 2025 citescomparesstate of the art
Unveiling Logic Bugs in SPJG Query Optimizations within DBMS 2025 citescomparesstate of the art
ZendDiff: Differential Testing of PHP Interpreter 2025 cites
A Review of Fuzz Testing for Configuration-Sensitive Software 2024 cites
Applications and Challenges for Large Language Models: From Data Management Perspective 2024 cites
Chronos: Finding Timeout Bugs in Practical Distributed Systems by Deep-Priority Fuzzing with Transient Delay 2024 citesuses or extends
Combining Structured Static Code Information and Dynamic Symbolic Traces for Software Vulnerability Prediction 2024 cites
DBStorm: Generating Various Effective Workloads for Testing Isolation Levels 2024 citesuses or extendscompares
Detecting Logical Bugs in DBMS via Isomerism Fuzz System 2024 citesuses or extends
Detecting Metadata-Related Logic Bugs in Database Systems via Raw Database Construction 2024 citesuses or extends
Differential Optimization Testing of Gremlin-Based Graph Database Systems 2024 citescompares
Dinkel: State-Aware and Granular Framework for Validating Graph Databases 2024 citescompares
DTD: Comprehensive and Scalable Testing for Debuggers 2024 cites
Dynamic Adjustment Paradigm based on Genetic Algorithm in Database Index Optimization 2024 cites
Leopard: A General Test Suite for Isolation Level Verification 2024 cites
Metamorphic Testing of Secure Multi-party Computation (MPC) Compilers 2024 cites
Mozi: Discovering DBMS Bugs via Configuration-Based Equivalent Transformation 2024 citescompares
NNTailor: A Neural Network-Driven Fuzzer for DataBase Management Systems 2024 citescompares
PolyJuice: Detecting Mis-compilation Bugs in Tensor Compilers with Equality Saturation Based Rewriting 2024 cites
Sedar: Obtaining High-Quality Seeds for DBMS Fuzzing via Cross-DBMS SQL Transfer 2024 cites
Semantic Conformance Testing of Relational DBMS 2024 citesuses or extendscomparesstate of the art
Software Security Analysis in 2030 and Beyond: A Research Roadmap 2024 cites
SQLess: Dialect-Agnostic SQL Query Simplification 2024 cites
SQLPass: A Semantic Effective Fuzzing Method for DBMS 2024 citescompares
Step-wise Execution of Data-Centric Systems 2024 citesstate of the art
T-Rec: Fine-Grained Language-Agnostic Program Reduction Guided by Lexical Syntax 2024 cites
Testing Constraint Checking Implementations via Principled Metamorphic Transformations 2024 cites
Testing Graph Database Systems via Equivalent Query Rewriting 2024 citescomparesstate of the art
Testing Graph Database Systems with Graph-State Persistence Oracle 2024 citesstate of the art
Testing Gremlin-Based Graph Database Systems via Query Disassembling 2024 citescompares
The Decision Problem for Regular First Order Theories 2024 cites
Towards Generic Database Management System Fuzzing 2024 citescompares
TRAP: Tailored Robustness Assessment for Index Advisors via Adversarial Perturbation 2024 cites
Understanding Transaction Bugs in Database Systems 2024 cites
Using query semantic and feature transfer fusion to enhance cardinality estimating of property graph queries 2024 cites
WingFuzz: Implementing Continuous Fuzzing for DBMSs 2024 citescomparesstate of the art
A Comprehensive Study of Real-World Bugs in Machine Learning Model Optimization 2023 cites
A Demonstration of DLBD: Database Logic Bug Detection System 2023 cites
Adapting Performance Analytic Techniques in a Real-World Database-Centric System: An Industrial Experience Report 2023 cites
An empirical study on configuration-related branch statement in database management system 2023 cites
Beyond the Coverage Plateau: A Comprehensive Study of Fuzz Blockers (Registered Report) 2023 cites
DAFuzz: data-aware fuzzing of in-memory data stores 2023 cites
Dependency-Aware Metamorphic Testing of Datalog Engines 2023 cites
Detecting Hidden Failures of DBMS: A Comprehensive Metamorphic Relation Output Patterns Approach 2023 cites
Detecting Isolation Bugs via Transaction Oracle Construction 2023 citesuses or extendscompares
Detecting Logic Bugs of Join Optimizations in DBMS 2023 citescomparesstate of the art
DynSQL: Stateful Fuzzing for Database Management Systems with Complex and Valid SQL Query Generation 2023 cites
EDEFuzz: A Web API Fuzzer for Excessive Data Exposures 2023 cites
Emerging Aspects of Software Fault Localization 2023 cites
Exploring Missed Optimizations in WebAssembly Optimizers 2023 cites
Fail through the Cracks: Cross-System Interaction Failures in Modern Cloud Systems 2023 cites
Finding Bug-Inducing Program Environments 2023 cites
Finding Unstable Code via Compiler-Driven Differential Testing 2023 cites
GDsmith: Detecting Bugs in Cypher Graph Database Engines 2023 citesuses or extends
Generating Test Databases for Database-Backed Applications 2023 cites
GrayC: Greybox Fuzzing of Compilers and Analysers for C 2023 cites
Pinolo: Detecting Logical Bugs in Database Management Systems with Approximate Query Synthesis 2023 citescomparesstate of the art
Property-Based Fuzzing for Finding Data Manipulation Errors in Android Apps 2023 cites
Randomized Differential Testing of RDF Stores 2023 cites
Retromorphic Testing: A New Approach to the Test Oracle Problem 2023 citesuses or extends
Sequence-Oriented DBMS Fuzzing 2023 citescomparesstate of the art
Siklus Hidup Pengembangan Sistem Basis Data Pada Sistem Informasi Buku Tamu di Badan Pusat Statistik Kabupaten Kediri Menggunakan MySQL 2023 cites
Squill: Testing DBMS with Correctness Feedback and Accurate Instantiation 2023 cites
Syntax-Aware Mutation for Testing the Solidity Compiler 2023 cites
Testing Database Systems via Differential Query Execution 2023 citesuses or extendscompares
Testing Graph Database Systems via Graph-Aware Metamorphic Relations 2023 citesuses or extends
Towards Better Semantics Exploration for Browser Fuzzing 2023 cites
A Disjoint-Partitioning Approach to Enhancing Metamorphic Testing of DBMS 2022 citesuses or extends
An Empirical Study on Quality Issues of eBay's Big Data SQL Analytics Platform 2022 cites
Automatic Detection of Performance Bugs in Database Systems using Equivalent Queries 2022 citescomparesstate of the art
Benchmarking Autonomy: A Taxonomy of Human-in-the-Loop Checkpoints for AI-Generated Transformation Code 2022 cites
DeepBench: Benchmarking JSON Document Stores 2022 cites
Demystifying and Checking Silent Semantic Violations in Large Distributed Systems 2022 cites
Detecting Logical Bugs of DBMS with Coverage-based Guidance 2022 citesuses or extendscomparesstate of the art
Differentially Testing Database Transactions for Fun and Profit 2022 citesuses or extends
Finding bugs in Gremlin-based graph database systems via Randomized differential testing 2022 citesuses or extends
Fuzzing DBMS via NNLM 2022 cites
GDsmith: Detecting Bugs in Graph Database Engines 2022 citesuses or extends
Griffin : Grammar-Free DBMS Fuzzing 2022 citescompares
Perfce: Performance Debugging on Databases with Chaos Engineering-Enhanced Causality Analysis 2022 cites
Unicorn: detect runtime errors in time-series databases with hybrid input synthesis 2022 citescomparesstate of the art
Artemis: An Automatic Test Suite Generator for Large Scale OLAP Database 2021 cites
Data-Oriented Differential Testing of Object-Relational Mapping Systems 2021 cites
Database System Development Life Cycle (DSDLC) on System Libraries for Data Manipulation Language (DML) Using SQL Server 2008 2021 cites
Differential Monitoring 2021 cites
Differential Monitoring - Technical Report ⋆ 2021 cites
Duplicate-sensitivity Guided Transformation Synthesis for DBMS Correctness Bug Detection 2021 cites
FoundationDB: A Distributed Unbundled Transactional Key Value Store 2021 cites
Generative type-aware mutation for testing SMT solvers 2021 cites
Industry Practice of Coverage-Guided Enterprise-Level DBMS Fuzzing 2021 citescompares
Metamorphic testing of Datalog engines 2021 cites
MT-Teql: Evaluating and Augmenting Neural NLIDB on Real-world Linguistic and Schema Variations 2021 cites
MTKeras: An Automated Metamorphic Testing Platform 2021 cites
Skeletal approximation enumeration for SMT solver testing 2021 cites
TCP-Fuzz: Detecting Memory and Semantic Bugs in TCP Stacks with Fuzzing 2021 cites
Technical Perspective DIAMetrics 2021 cites
Testing DBMS Performance with Mutations 2021 citescompares
Verifying Serializability Protocols With Version Order Recovery 2021 cites
On the unusual effectiveness of type-aware operator mutations for testing SMT solvers 2020 cites
SQUIRREL: Testing Database Management Systems with Language Validity and Coverage Feedback 2020 cites
Testing query execution engines with mutations 2020 cites

Resources (24)

Material other people have made about SQLancer or one of its techniques. Pages that merely mention it in passing are left out, and so is the project's own material — this site already links its documentation, papers and blog, and repeating them here would say nothing about reach.

Blog posts (8)

Documentation notes (3)

  • Apache DataFusion contributor guide: testing
    You can run these tests individually using cargo as normal command such as cargo test -p datafusion --test parquet_integration SQL “Fuzz” testing # DataFusion uses the SQLancer for “fuzz” testing: it generates random SQL queries and execute them against DataFusion to find bugs.
  • How SQLite Is Tested
    One fuzzing researcher of particular note is Manuel Rigger.
  • Why DuckDB
    Result validation: Manuel Rigger used his excellent SQLancer tool to verify DuckDB result correctness.

External talks (9)

  • Reliability Lessons From SQLite - Richard Hipp | SSW 2026 (2026) · 2 mentions
    SQLite's creator on twenty-six years of testing it, crediting Rigger with the idea of fuzzing for inconsistencies in SQL rather than for crashes, explaining the sub-query equivalence that finds them, and saying SQLite's own fuzzer had to be extended to do the same.
    The slide behind him is SQLite's project timeline: query fuzzing arrives around 2020, after 3.0.0, 100% MC/DC coverage and profile-guided fuzzing.
    The slide behind him is SQLite's project timeline: query fuzzing arrives around 2020, after 3.0.0, 100% MC/DC coverage and profile-guided fuzzing. Watch at 47:16
  • The Art of Database Testing by Alperen Keles | DC Systems 011 (2026) · 3 mentions
    A survey of database testing methodology that walks an audience through SQLancer's oracles, naming pivoted query synthesis outright and putting ternary logic partitioning on a slide; the tool itself comes up again in questions.
    The slide behind the speaker is SQLancer's logo above its eight oracles, named in full: PQS, NoREC, TLP, DQE, QPG, CERT, DQP and CODDTest.
    The slide behind the speaker is SQLancer's logo above its eight oracles, named in full: PQS, NoREC, TLP, DQE, QPG, CERT, DQP and CODDTest. Watch at 3:25
  • Fuzzing databases is difficult (2025) · 4 mentions
    A ClickHouse engineer on how the system is fuzzed. SQLancer appears on the early list of the fuzzers ClickHouse runs, again where the talk explains detecting wrong results by comparing equivalent queries, and once more in the closing recommendations.
    The slide "Testing with Fuzzers" names the fuzzers ClickHouse runs, SQLancer first among them.
    The slide "Testing with Fuzzers" names the fuzzers ClickHouse runs, SQLancer first among them. Watch at 1:50
    The slide "Finding wrong results" credits SQLancer by name with pioneering the comparison of equivalent queries against an oracle.
    The slide "Finding wrong results" credits SQLancer by name with pioneering the comparison of equivalent queries against an oracle. Watch at 13:47
  • FUZZING'25 Keynote: "Constraining Fuzzing without Paying Too Much" by Miryung Kim (2025) · 1 mention
    A fuzzing keynote that puts SQLancer in its table of what building a custom fuzzer costs, at 28:23.
    The keynote's table of what fuzzer customisations cost to build lists SQLancer among them, with its contributor, commit and paper counts.
    The keynote's table of what fuzzer customisations cost to build lists SQLancer among them, with its contributor, commit and paper counts. Watch at 28:23
  • [FUZZING'23] "Three Colours of Fuzzing: Reflections and Open Challenges" Keynote by Cristian Cadar (2023) · 4 mentions
    A fuzzing keynote that reaches for SQLancer as its example of a fuzzer that found hundreds of bugs in mature database systems, and later reads out SQLite's own line about the project's author, agreeing with it.
    A slide of fuzzers that made a difference — KLEE, SAGE, AFL, OSS-Fuzz, Csmith and EMI — ending with SQLancer as the DBMS fuzzer, with the bug count it found in popular database systems.
    A slide of fuzzers that made a difference — KLEE, SAGE, AFL, OSS-Fuzz, Csmith and EMI — ending with SQLancer as the DBMS fuzzer, with the bug count it found in popular database systems. Watch at 4:55
    The slide displays SQLite's own paragraph about the project's author, attributed on the slide to the SQLite webpage. Its wording is in the dataset already, quoted from sqlite.org/testing.html.
    The slide displays SQLite's own paragraph about the project's author, attributed on the slide to the SQLite webpage. Its wording is in the dataset already, quoted from sqlite.org/testing.html. Watch at 25:09
  • ClickHouse Release 22.3 Webinar (2022) · 1 mention
    The release webinar's section on continuous integration lists SQLancer among the fuzzing methods ClickHouse runs, beside libFuzzer, the AST query fuzzer and Jepsen.
    See the slide
  • Keynote 1: DuckDB Testing - Present and Future (2022) · 6 mentions
    DuckDB's testing, from one of its authors: the keynote credits SQLancer with around eighty bugs that the SQLite and Postgres test suites DuckDB had borrowed all missed, argues for running it beside SQLsmith because each finds what the other does not, and says the robot in DuckDB's CI runs both.
    The slide behind the story: “and then Dr. Rigger came along!”, over a DuckDB bug report.
    The slide behind the story: “and then Dr. Rigger came along!”, over a DuckDB bug report. Watch at 35:44
    The next slide puts a number on it: the bugs SQLancer found in DuckDB, which the test suites DuckDB had borrowed from other systems did not.
    The next slide puts a number on it: the bugs SQLancer found in DuckDB, which the test suites DuckDB had borrowed from other systems did not. Watch at 36:10
    The robot that runs fuzzers in DuckDB's CI, and what it was running at the time: SQLancer and SQLsmith.
    The robot that runs fuzzers in DuckDB's CI, and what it was running at the time: SQLancer and SQLsmith. Watch at 40:55
  • Fuzzing: Practical approaches in ClickHouse (2021) · 1 mention
    A tour of everything ClickHouse fuzzes with, giving SQLancer a section of its own: who wrote it, who brought it into ClickHouse, and what it does.
    See the slide
  • CockroachDB's Query Optimizer (Rebecca Taft, Cockroach Labs) (2020) · 1 mention
    CockroachDB's optimizer, from an engineer who builds it; asked in the questions about random testing, she separates SQLsmith's crashes from the logical bugs Rigger was after, credits him with a batch of GitHub issues against CockroachDB, and says she is trying to get SQLancer running in their own system.

Tools (4)

  • go-sqlancer
    go-sqlancer: re-implementation of some of SQLancer's approaches in Go by PingCAP
  • go-sqlancer (PingCAP-QE)
    Go-sqlancer Inspired by Manuel Rigger's paper Testing Database Engines via Pivoted Query Synthesis.
  • sqlancer-iris
    SQLancer-IRIS Automated SQL Testing for InterSystems IRIS Using Differential Oracles sqlancer-iris is an extension of the SQLancer project that enables automated detection of logical bugs in InterSystems IRIS SQL engine.
  • SQLRight
    SQLRight: coverage-guided DBMS fuzzer, also supporting NoREC and TLP

Methodology and attribution policy

These are the rules the dataset is built to. They are stored as data (policy.json) and rendered here, so the policy the collectors enforce and the policy described on this page cannot drift apart.

What this page counts

Every number on this page is computed from structured records stored in this website's repository under _data/impact/. Each record carries the primary source that justifies it, so any figure can be traced back to a bug report, a paper, a repository, or a published resource.

Records are proposed by an automated pipeline that runs weekly, but nothing is published without passing schema validation, and every claim that required a judgement call retains the exact excerpt it was based on. Candidates for which the evidence is inconclusive are rejected rather than rounded up.

include A record is published only when it carries at least one link to a primary source. Excerpts stored as evidence are copied verbatim from that source; they are never paraphrased or generated.

exclude Candidates classified as uncertain or as having insufficient evidence are never promoted into a positive category. They are recorded as rejected and are excluded from all counts.

note Two kinds of evidence carry no quotation. A frame captured from a talk shows what was on the slide instead of quoting it, because text read off a picture cannot be checked against a fetched source the way every other excerpt is. And a passage the PDF set with letter-spacing is described rather than printed: extraction returns it one character at a time and the word breaks are not in the file to restore, so no readable form of it exists to quote.

The SQLancer umbrella

SQLancer is the main testing tool, but the project also covers explicitly designated components such as SQLancer++ and ShQveL. Results produced by any umbrella component count towards the overall SQLancer impact statistics.

Individual tools are never collapsed into a single unstructured label. Every record preserves both the tool that produced the result and, where known, the specific technique responsible, so the contribution of each component stays visible.

note Each bug record stores a finder (for example sqlancer, sqlancer_pp or shqvel) and a technique (for example norec or tlp, or null when the report does not identify one).

Bugs found by SQLancer

A bug counts as found by SQLancer when the available evidence connects it to SQLancer or to a testing technique that was introduced as part of SQLancer. Bug reports frequently name the test oracle rather than the tool, so a report that credits NoREC, TLP, PQS or QPG is attributed to SQLancer even when it never uses the word “SQLancer”.

Reported bugs that the developers rejected as invalid or duplicate remain in the dataset for transparency, but they are excluded from the headline bug count. Only reports accepted as genuine bugs (fixed, verified, or still open) are counted.

The count is a floor rather than a total. A report reaches this dataset only when something public ties it to SQLancer, and a great deal of the testing leaves no such trace: bugs in closed-source systems are usually reported privately, a report is written about the bug rather than about what found it, and a project can run SQLancer routinely while fixing what it finds without ever naming the tool. Projects known to run SQLancer and contributing no bug at all to this page are the visible part of that gap; the invisible part cannot be sized from here.

One clause above rests on the reporter rather than on the report, and it is the weakest thing here, so it is labelled rather than blended in: those records carry the rule campaign_reporter and a confidence of low, and they cite the roster entry that admitted them alongside the report itself.

include A primary source explicitly states that SQLancer, SQLancer++ or ShQveL found the bug.

include The bug report attributes the discovery to a SQLancer-originated test oracle or technique, such as NoREC, TLP, PQS or QPG, even if SQLancer itself is not named.

include The reporter and the surrounding evidence otherwise establish that the report resulted from a SQLancer testing campaign, for example because it comes from the project's own curated bug repository.

include A defect report filed in a database system's own tracker by a member of the project or of the TEST lab counts as a SQLancer bug, whether or not the report names a tool. These people report database bugs because they run SQLancer campaigns, and a report is written about the bug rather than about what found it -- most of them never mention the tool, and reproducers are usually minimised by hand before filing, which removes the generated schema too. Such a record is marked with the rule campaign_reporter at low confidence, and its evidence names the roster it rests on, so every claim resting on who reported it can be found and re-judged.

exclude Bugs found with database-testing techniques developed independently of SQLancer are not counted, even when an implementation of the technique later landed in the SQLancer repository. EET and DQE are the concrete cases: both were introduced elsewhere and contributed to SQLancer afterwards, so bugs attributed to them are not SQLancer findings, and work citing their publications is not counted as citing SQLancer.

exclude A bare mention of an ambiguous acronym such as TLP or PQS is not sufficient. Corroborating database-testing context is required before the match is treated as a SQLancer attribution.

exclude A defect report filed against a graph database system by a member of the project or the lab is not counted. The lab tests graph systems with tools developed independently of SQLancer, and SQLancer has no provider for any of them, so the reporter's name is not evidence of a SQLancer campaign there.

Papers and how they relate to SQLancer

Papers are discovered from the citation graphs of the foundational SQLancer publications. Every paper that cites one of them is collected, and each is then classified into four overlapping relationships. A paper can hold several relationships at once, so the overall paper count deduplicates: a paper that both reuses the codebase and compares against SQLancer is counted once.

A fifth relationship records recognition rather than use: papers that call SQLancer or one of its techniques the state of the art. It is kept out of the “builds on” total on purpose, since describing a tool and building on one are different things.

include references — the paper cites a foundational SQLancer publication. Established deterministically from the citation graph, so no judgement is involved.

include uses_infrastructure — concrete evidence that the paper's implementation uses or derives from the SQLancer codebase: an artifact based on the SQLancer repository, retained SQLancer source files or its package structure, SQLancer copyright notices or build coordinates, source history derived from SQLancer, or a README describing the reuse. This category is decided by inspecting the artifact, not from wording in the paper, because a paper that reuses the codebase very often says so nowhere — neither in its text nor in its artifact's README. No single signal is decisive on its own: the presence of Randomly.java, say, is weighed together with the rest.

include extends_technique — the authors extend, generalise, adapt or substantially build upon a technique introduced through SQLancer, for instance by generalising TLP to a new setting or extending NoREC with a new transformation. This is the most qualitative category; each accepted classification retains the exact excerpts that justify it.

include compares_with — the paper empirically evaluates its approach against SQLancer, a SQLancer implementation, or a SQLancer test oracle.

include describes_as_state_of_the_art — the paper describes SQLancer or one of its techniques as the state of the art. This is read directly off the citing sentence, which is quoted in full: a citation context is a single sentence, so one containing both the phrase and a SQLancer name is saying the one about the other. It is recognition rather than reuse, so it is reported separately and is not part of the count of papers building on SQLancer.

exclude Publications that are part of the SQLancer project itself are marked as such and excluded from counts of external work building on SQLancer. A paper counts as ours if one of the project's authors is on it, if it is the paper that introduced one of the techniques or tools listed above, or if the project lists it explicitly. Co-authorship settles it on its own, whatever the paper is about: our own follow-up work is not external adoption, and counting it as such would flatter the numbers.

Database systems using SQLancer

Three different things are tracked separately and never conflated: database systems that SQLancer can test, database systems in which SQLancer has found bugs, and database system projects whose own developers use or integrate SQLancer.

The fact that SQLancer supports a database system says nothing about whether that project uses it. Adoption is recorded only when the evidence comes from the database system's own project or developers.

A fourth thing is recorded and deliberately counted towards nothing: a project whose developers have proposed adopting SQLancer without anything yet showing the project running it. An intention is not use, so these are kept apart under planned_adoption, listed on their own page, and included in no figure here. A proposal from a project's own developers is worth recording, and it is the thing to re-check later: some become adoption and others do not.

include official_ci — the project runs SQLancer in its own continuous integration.

include official_testing — the project maintains SQLancer scripts, configuration or testing documentation outside CI.

include developer_use — a developer of the project describes using SQLancer, for example in an issue, pull request, blog post or documentation they authored.

include integration_contributed_by_dbms_team — the SQLancer integration for that system was contributed or is maintained by the database system's team.

exclude Support by SQLancer alone is never adoption evidence, and neither is a third party testing a database system with SQLancer.

note planned_adoption -- a proposal, a roadmap entry or a testing plan from the project's own developers, with nothing yet showing them running SQLancer. Superseded the moment adoption evidence arrives, so a project that has both is counted as using it and listed only there.

Resources

Resources are curated pointers to material other people have made about SQLancer or one of its techniques — talks, blog posts, documentation notes, datasets, artifacts and tools. Two things are deliberately excluded: pages that merely mention SQLancer in passing, and the project's own material. The site already links its own documentation, papers and blog, and listing them here would pad the count without saying anything about reach.

include Every resource carries a canonical URL, a type from a fixed vocabulary, a short factual description, and the source metadata it was collected from.

exclude Material published by the SQLancer project itself is not a resource here, whether it is hosted on the project's own properties or simply named after it.

How the data is collected

Discovery is deterministic. Bug records come from the project's own curated bug repository, from targeted GitHub searches for SQLancer and its technique names, from the forks that database system vendors maintain of SQLancer itself, which list the bugs each provider found, from vendor trackers that are not GitHub -- MariaDB's Jira, openGauss's Gitee -- and from the NUS TEST lab's published bug list — though nothing from that list is admitted for being on it: each candidate is taken back to its own bug report and put through the same attribution rules as any other. Papers come from scholarly citation APIs. Adoption evidence comes from code, workflow and issue searches scoped to database system repositories.

One route deserves spelling out, because most bug reports never mention SQLancer at all — a report is written about the bug, not about what found it. Searching for the tool's name therefore misses them. So the people who run SQLancer campaigns are recorded, each linked to their GitHub profile and each link established from issues they are credited with rather than assumed, and their reports are read whether or not they name the tool. Two things can then admit a report. The stronger is the reproducer itself: SQLancer generates its own schema, so its reproducers create tables named t0, t1 with columns c0, c1, a shape the tool leaves on the report even when the reporter says nothing. The weaker is membership alone, for the many reports whose reproducer was minimised by hand before filing and so carries no such trace; those are marked campaign_reporter at low confidence and cite the roster openly, so a reader can see exactly which claims rest on who reported them.

A language model is used only to answer bounded questions about material that deterministic collection has already found — for example whether an issue attributes a bug to a SQLancer technique, or whether a paper extends one. It is given the fetched source text and must answer yes, no, uncertain, or insufficient evidence, quoting the passage it relied on. It is never asked to browse the web, and it cannot introduce a record on its own.

Classifications are cached against the hash of the evidence, the policy version and the taxonomy version, so unchanged material is never reclassified. Proposed changes are opened as a pull request for human review rather than published directly.

The data itself

The records are plain JSON, each file validated against a JSON Schema on every change:

  • bugs.json — bug reports attributed to SQLancer, with the evidence for each attribution.
  • papers.json — papers citing SQLancer and their relationships to it.
  • adoption.json — evidence that a database system's developers use SQLancer.
  • resources.json — talks, tutorials, documentation and other material.
  • talks.json — recorded talks, with every point where SQLancer comes up, what was read to find it, and how far those words can be trusted.
  • _data/papers/ — one file per paper that cites SQLancer, holding every sentence in it that mentions the project and the classification each of those sentences supports.
  • dbms.json — the database system registry.
  • techniques.json — the technique and tool taxonomy.
  • people.json — the people who run SQLancer campaigns, linked to their GitHub profiles. It decides whose reports are worth reading, and attributes nothing by itself.
  • stats.json — the derived figures this page renders, regenerated from the records above.

Found something wrong, or a bug, paper or tool that is missing? Open an issue — the dataset is meant to be corrected in public.