Rewrite datafusion-sqlancer in Rust

[2010YOUY01]

Is your feature request related to a problem or challenge?

This a project idea for GSoC 2025 #14478

datafusion-sqlancer is a SQL level fuzz testing implementation for DataFusion. #11030

Current implementation status

datafusion-sqlancer has covered partial SQL features, and data types, and implemented 3 relatively simple testing oracles¹. With occasional manual runs, around 50 bugs have been found.
The implementation is in Java, and it's a fork of the original SQLancer.

Why rewrite in Rust

The SQLancer was first implemented in Java for very good reasons: it has to test the effectiveness of several testing oracles on many major databases, JDBC is a common interface.
DataFusion's SQLancer implementation now is done by extending SQLancer framework, it has saved us some effort to do CLI parsing, result comparison, etc.

There are several reasons I think it's a good idea to rewrite in Rust at this point:

• (major) Making test oracles also apply to sqllogictests
datafusion-sqlancer consists of two modules: random query generation, and property validation for test oracles. Those properties can also be applied to enhance existing SQL tests. If we have those properties implemented in Rust, enhancing existing sqllogictests would be easier.
  Now only 3 simple test oracles have been implemented, and I believe there are around 10 novel SQL testing algorithms have been proposed, one example is Equivalent Expression Transformation(https://www.usenix.org/conference/osdi24/presentation/jiang). EET I think is very suitable to enhance existing SQL tests.
  Overall, I think it's a good time to switch to native rust implementation before implementing more complex testing algorithms.
• Simplier implementation
  One thing we simplify is now we don't have to use JDBC to connect the testing framework and DataFusion core, configuration fuzzing can be easier, and there might be some existing code we can reuse.
• More contributors
  DataFusion ecosystem is mainly in Rust, IMO it would be easier to find people to help if the testing framework is written in Rust instead of Java.

Describe the solution you'd like

See #11030 for the background

• Generate random query to a datafusion internal data structure (perhaps Statement)
• Implement testing oracles. In order to support also running with existing SQL tests, we might want:
  • For query mutation: mutate the query's internal representation, and convert it back to SQL string
  • For property check: implement by extending sqllogictest framework

Describe alternatives you've considered

The project idea proposed above I believe is advanced in terms of difficulty.
A medium level project can be extending existing implementation with more SQL/types support, and implement more test oracles, also with better CI integration.
I'm also open to a fully LLM-based alternative, however I don't have a very good idea so far. Reference https://fuzz4all.github.io/

Additional context

No response

Footnotes

1. https://github.com/apache/datafusion/issues/11030 has a minimal example for testing oracle NoREC ↩

[alamb]

I bet we are not the only project that would like to have SQLLancer type support in Rust

Perhaps we can join forces (aka with Risingwave)

ps. @Xuanwo -- here is another example of "rewrite it in Rust!"

[Xuanwo]

I bet we are not the only project that would like to have SQLLancer type support in Rust

That's really cool! Databend will definitely be interesting in building this project. So does iceberg-rust.

[andkolbe]

Hello, I am interested in applying to work on this project for GSoC. After reading through #11030 , it looks like the three testing oracles that have been implemented from SQLancer are NoREC, TLP, and PQS. Were those chosen because they were the easiest to implement, or was there something about how they test Datafusion specifically?

[2010YOUY01]

Hello, I am interested in applying to work on this project for GSoC. After reading through #11030 , it looks like the three testing oracles that have been implemented from SQLancer are NoREC, TLP, and PQS. Were those chosen because they were the easiest to implement, or was there something about how they test Datafusion specifically?

👋🏼 They're implemented first because

• All of them are general-purpose algorithms, which should work in most systems:
  • Taking TLP for example, it's targeting edge case value handling (NULLs) so it should work well for DataFusion.
  • NoREC: It's checking the consistency between optimized (by predicate pushdown) path and non-optimized path, and also it's checking the consistency between how a same predicate is evaluated in select expr and where expr, it also caught several bugs for DataFusion
  • PQS: I don't have very good intuition on why this one should work and I think it has caught 0 or 1 bug 🤦🏼 Perhaps I'm missing something.
• Yes, they're also very easy to implement.

To make fuzzing more specific to DataFusion, I think the most needed is configuration fuzzing or data source fuzzing. To make DataFusion more performant. For the same executor there are many specialized execution paths, and they're controlled by turning different configuration knobs in https://datafusion.apache.org/user-guide/configs.html
However, they're quite hard to implement due to the complexity. Given a randomly generated query, if we pick a random configuration for every option, it's very likely to fail, becuase this configuration is invalid, I believe given a specific query only a small subset of the configurations are relevant. So now we implement this kind of configuration fuzzing separately, for example https://github.com/apache/datafusion/blob/main/datafusion/core/tests/fuzz_cases/aggregation_fuzzer/mod.rs
I wish configuration fuzzing can be integrated into datafusion-sqlancer, but it still has a long way to go.

[andkolbe]

Thank you very much for your quick and thorough response. I'll keep digging

[xudong963]

I bet we are not the only project that would like to have SQLLancer type support in Rust

That's really cool! Databend will definitely be interesting in building this project. So does iceberg-rust.

Hi @Xuanwo 😄 , how's it going?