I got mass fed up with data quality tools, so I built my own

I work as a data engineer. BigQuery, Athena, Polars, the usual stack. Every project I've been on had the same problem: how do you check that your data isn't garbage before it hits the dashboard?

I tried everything. GX took 90 seconds on 41 million rows. Soda pulled 30+ dependencies and wanted me to pay for basic things like seeing if my null rate went up since yesterday. Pandera was decent for DataFrames but couldn't talk to a warehouse.

None of them gave me what I actually wanted: run checks, show me what failed, tell me how many rows, give me samples. Fast. On any source.

So I built Eliza DQ.

What it actually does

You point it at something (a BigQuery table, a parquet file, a DataFrame, whatever) and tell it what to check.

from eliza import check

result = check("data.parquet", checks={
    "order_id": ["not_null", "unique"],
    "amount":   ["not_negative"],
    "email":    ["is_email"],
})

print(result.summary())
# "2 passed, 2 failed (1M rows, 12ms)"

For warehouses you write a YAML config and run from CLI:

pip install eliza-dq[bigquery]
eliza check --config orders

You get back fail counts, fail rates, sample failing rows, PDF report if you want one, Slack alert if you set it up. Not just "pass/fail". Not just an exception with no context.

2 dependencies total. polars + pyyaml. That's the whole thing.

The thing that actually made me build this

It was sample queries. When a check fails, you want to see which rows are broken. Makes sense. Soda does this by running SELECT * for every failing check. On a 48-column BigQuery table, that means scanning all 48 columns just to show you one column that failed.

Here's the thing about BigQuery pricing that a lot of people don't realize: LIMIT doesn't reduce cost. The price is determined by which columns are in your SELECT, not how many rows come back. So SELECT * FROM table WHERE col IS NULL LIMIT 100 costs the same as scanning the entire table.

Eliza runs SELECT id, failing_column instead. 2 columns, not 48. That's 24x less data per sample query. And it runs them in parallel instead of one by one.

Real numbers on a 5-billion-row table, 25 checks, 21 of them failing:

If you run 10 failing checks daily on a 1TB table, that's $3,200/year vs $25,000 in BQ costs. Just from being smarter about which columns you scan.

Benchmarks

I spent a lot of time on these because I got burned early. First version of the README had inflated numbers from BQ query cache. A community tester called me out on it, and he was right. So now everything is measured properly: same checks, same data, warmup discarded, min of 3 runs.

DataFrames (NYC Yellow Taxi, all in memory):

Most of the speed comes from Polars, not from me being clever. I group checks by column so each column is scanned once, and Polars streaming does the rest. Credit where it's due.

Streaming from files:

259 million rows across 72 parquet files: 1.3 seconds, under 1GB RAM. Other tools need to load everything into memory first and OOM on an 8GB machine.

SQL pushdown (you can reproduce this yourself):

pip install eliza-dq soda-core-duckdb
python benchmarks/sql_local.py

What Soda doesn't give you for free

Soda Core (the open source version) has zero persistence. Run finishes, results are gone. Want to see if your null rate went up? Want anomaly detection? Want any kind of history? Pay for Soda Cloud.

I get why they do it. But for a small team or a solo DE, paying $10K+ a year for "your data got worse since last Tuesday" is a lot.

I'm building run history into Eliza with SQLite by default (zero config) and optional write-to-your-DWH. Anomaly detection, trends, the whole thing. Free, open source, your data stays with you.

Try it

pip install eliza-dq

GitHub: github.com/Se7enquick/eliza-dq

17 checks, 8 warehouse connectors, PDF reports, Slack alerts. MIT license. I use it in production myself.

If something breaks, open an issue. I read all of them.