Scope comparison¶

rand-engine, Faker, and dbldatagen overlap in synthetic-data work while using different execution and deployment models. The table records only capabilities described by the linked primary sources; it is not a ranking.

Use Faker for provider-oriented values, dbldatagen for its Spark/Databricks-oriented generation workflows, and rand-engine where its RandSpec, stateless relations, pandas outputs, or optional Spark facade fit the application. These descriptions identify overlap, not equivalent feature sets.

rand-engine regression evidence¶

The recorded results and same-runner methodology measure rand-engine base and head revisions under one runner. These are rand-engine regression measurements, not a Faker or dbldatagen speed comparison.

Bounded CI observations¶

The following observations come from one successful, validated GitHub Actions run at harness commit bff8526cc6a5d76cb2cb8a454b69971cbf0876a5. Its retained artifact contains the machine-readable record and derived summary. The artifact was 74,765 bytes, had SHA-256 6cd6cd39239839fc38b8d021c9bc19ea33b451d5f5db21f820ba55c0c3e90a0f, and is scheduled to expire on 2027-01-16T18:14:24Z; the raw values are retained here so the observations do not depend on artifact access.

This was one GitHub-hosted Ubuntu/Linux x64 run (GitHub Actions 1000038864) on Python 3.12.15, Java (version components: 17, 0, 20, 1), and Spark 3.5.8 in local[8]. It installed the public, non-editable rand-engine 0.8.0 wheel (SHA-256 db4422a43a20605babb369ac223d526e5607f6539f5056c5d277ead22ad173ba) in an isolated environment. The direct comparison pins were Faker 28.4.1, dbldatagen 0.4.0.post1, PySpark 3.5.8, NumPy 2.1.1, pandas 2.2.3, PyArrow 23.0.1, setuptools 83.0.0, jmespath 1.0.1, and pyparsing 3.2.5.

Each side had one warm-up, then three timed samples in AB/BA/AB order. Setup, warm-up, and output validation were outside the timed generation samples. For the Python workload, DataGenerator and Faker were seeded with 42. For Spark, rand-engine's seed 42 controls its key generation only; dbldatagen used randomSeed=42 and hash_fieldname. The Spark payload values are not claimed to repeat exactly across the two implementations.

The shared Python contract was exactly 100,000 dictionaries with value: int in 0..999999, tier: str in bronze, silver, or gold, and active: bool. The timed rand-engine call was DataGenerator(...).get_df().to_dict("records") followed by scalar normalization; Faker used direct providers for the same fields. Validation of all 100,000 outputs was outside the clock. stream_dict was not used.

The Spark contract built and fully evaluated 1,000,000 rows at eight partitions. Each timed call built its frame, selected xxhash64(ordinal, value, tier), then aggregated count(*) and the hash sum with collect(). Both observed schemas were ordinal: bigint (not nullable), value: int (nullable), and tier: string (nullable); the observed null counts were zero. Validation also recorded ordinal range 0..999999, one million distinct ordinals, and the common value and tier domains. The recorded physical plans show the hash consumes all three payload columns, rather than only counting rows.

The immutable runner, pinned requirements, and workflow at that harness commit provide the exact invocation. The workflow installs the public wheel in an isolated environment and runs the harness from outside the checkout with that environment's interpreter.

These observations apply only to these two contracts, pins, runner, and three-repetition run. They are not production-throughput measurements or claims of universal speed, adoption, causal architecture, or statistical ranking. No winner is inferred.