Reminds me a bit of Snaplet before it embarked on its incredible journey to get acquired by Supabase and shut down.
I like the concept but the painpoint has never been around creating realistic looking emails and such like, but creating data that is realistic in terms of the business domain and in terms of volume.
Appreciate the Snaplet comparison, they were doing good work. You're right that realistic looking strings are the easy part. We're focused on relational integrity first (FKs, constraints, realistic cardinality), but business domain logic is the next layer. What kinds of rules would be useful for you? Things like weighted distributions, time-based patterns, conditional relationships?
The realistic cardinality is actually a good start (the problem with things like using Faker for DB seeds being that everything is entirely too random).
If one were be able to use metrics as source then, depending on the quality of the metrics, it might be possible to distribute data in a manner similar to what's observed in production? You know, some users that are far more active than others, for example. Considering a major issue with testing is that you can't accurately benchmark changes or migrations based on a staging environment that is 1% the size of your prod one, that would be a huge win I think even if the data is, for the most part, nonsensical. As long as referential integrity is intact the specifics matter less.
Domain specific stuff is harder to describe I think. For example, in my setup I'd want seeds of valid train journeys over multiple legs. There's a lot of detail in that where the shortcut is basically to try and source it from prod in some way.
This is useful. What if you ran a CLI locally that extracts just the statistical profile from prod cardinality, relationship ratios, etc. and uploaded that? We'd never touch your database, you just hand us the metrics and we match the shape.
Hey! Snaplet founder here. Want to clarify that it was not acquired by Supabase; I shutdown the startup and found roles for some of the team at Supabase.
A while ago I worked on a similar idea, it was back when I was learning Rust so not super proud of the code, but I love the name of the tool: https://github.com/gistia/joindoe
Streaming: Can't hold it all in memory. Generate in chunks, write, release, repeat.
Format choice: Parquet with row groups is fast and compresses well. SQL needs batched inserts (~1000/statement). Direct DB writes via COPY skip serialization entirely is usually fastest.
FK relationships: The real bottleneck. Pre-generate parent PKs, hold in memory, reference for children. Gets tricky with complex graphs at scale.
Parallelization: Row generation is embarrassingly parallel, but writes are serial. Chunk-then-merge is on our radar but not shipped yet.
What does your stat product need, realistic distributions or pure volume/stress testing?
does it handle skewed distributions? faker's always been useless for this - like, your test data ends up with everyone having 5 orders when real data is all long tail
Thanks for the feedback! Honestly, we're still dialing in the tiers, what row limits would feel reasonable to you for your use case? Always helpful to hear what people actually need.
To be honest, I think 1M rows is starting point for any paid plan. Any data model of minimal complexity explodes fast, especially with cascading one-to-many relationships. If anything, it may make more sense to have a table-level, rather than a global, limit. Or put the limit on "trunk" tables.
That is a really good point one-to-many relationships blow up fast. The trunk table idea is interesting, would simplify how people reason about limits. Appreciate the feedback, genuinely helpful!
Different focus, ShadowTraffic is config-driven and optimized for streaming/Kafka workloads. We're schema-driven: point us at your DDL and we generate relational test data automatically. Less config, more just give me test data that fits my tables.
This is a great idea. I've thought about doing something similar! On the other hand, I'm not sure it's a business. Is this using AI?
The pricing seems extremely high for what's basically a call to https://github.com/faker-ruby/faker but that makes sense if it has to pay for OpenAI tokens.
(who knows though, plenty of B2B deals signed for sillier things than this - good luck, OP)
Thanks! To clarify, the core engine isn't AI. It's deterministic pattern matching, so it runs in milliseconds with no token costs. There's an optional "Story Mode" that uses AI for narrative-coherent data (like "a churning SaaS with seasonal trends"), but the base product is just schema parsing + smart type inference.
The difference from Faker: you don't write any code. Paste your CREATE TABLE, get data back. Faker is a library you have to integrate, configure field-by-field, and maintain as your schema changes. Different use case — more like "I need a seeded database in 30 seconds" vs "I'm building a test suite."
Fair point on pricing though, still figuring that out. Appreciate the feedback.
Real Test data génération as saas was not a viable business for us.
Developers use their tool or develop a script (with ai or not)
We made it free, the value comes when you can use it in your development process.
https://www.tabulify.com/learning-tabulify-step-9-how-to-fil...
The cost of calling a service is also not free.
In all case, all the best in your endeavour.
Reminds me a bit of Snaplet before it embarked on its incredible journey to get acquired by Supabase and shut down.
I like the concept but the painpoint has never been around creating realistic looking emails and such like, but creating data that is realistic in terms of the business domain and in terms of volume.
Appreciate the Snaplet comparison, they were doing good work. You're right that realistic looking strings are the easy part. We're focused on relational integrity first (FKs, constraints, realistic cardinality), but business domain logic is the next layer. What kinds of rules would be useful for you? Things like weighted distributions, time-based patterns, conditional relationships?
The realistic cardinality is actually a good start (the problem with things like using Faker for DB seeds being that everything is entirely too random).
If one were be able to use metrics as source then, depending on the quality of the metrics, it might be possible to distribute data in a manner similar to what's observed in production? You know, some users that are far more active than others, for example. Considering a major issue with testing is that you can't accurately benchmark changes or migrations based on a staging environment that is 1% the size of your prod one, that would be a huge win I think even if the data is, for the most part, nonsensical. As long as referential integrity is intact the specifics matter less.
Domain specific stuff is harder to describe I think. For example, in my setup I'd want seeds of valid train journeys over multiple legs. There's a lot of detail in that where the shortcut is basically to try and source it from prod in some way.
This is useful. What if you ran a CLI locally that extracts just the statistical profile from prod cardinality, relationship ratios, etc. and uploaded that? We'd never touch your database, you just hand us the metrics and we match the shape.
We do exactly that in one of our products. It's called data profiling.
I'd be willing to try that out :) a CLI would be great, even as a sandbox tool
Really appreciate the input. I'll make sure to give you early access once we implement this, I'll keep you posted.
Hey! Snaplet founder here. Want to clarify that it was not acquired by Supabase; I shutdown the startup and found roles for some of the team at Supabase.
The code remains:
- https://github.com/supabase-community/seed - https://github.com/supabase-community/copycat - https://github.com/supabase-community/snapshot
This looks like a great project, wishing them all the best on the journey.
Thanks!! means a lot coming from you. Best of luck at Supabase.
Thanks, but I am not at Supabase! I ended up going back to building RedwoodJS and took over the project, and now have a consultancy.
Vibe-coded one using LLM (only for semantic understanding of columns). Works well: https://github.com/freakynit/postgre-data-generator
I have something that gives you the data in CSV/SQL insert statements.
I also provide an option to select how to generate data for specific fields.
https://fakemydb.alles-tools.com
UI is a bit clunky - will revamp it :)
Great minds think alike!
A while ago I worked on a similar idea, it was back when I was learning Rust so not super proud of the code, but I love the name of the tool: https://github.com/gistia/joindoe
Congrats on being launchable!
I've written seed data scripts a number of times, so I get the need. How do you think about creating larger amounts of data?
E.g., I'm building a statistical product where the seed data needs to be 1M rows; performance differences between implementations start to matter.
Thanks! At 1M rows, I think a few things matter:
Streaming: Can't hold it all in memory. Generate in chunks, write, release, repeat.
Format choice: Parquet with row groups is fast and compresses well. SQL needs batched inserts (~1000/statement). Direct DB writes via COPY skip serialization entirely is usually fastest.
FK relationships: The real bottleneck. Pre-generate parent PKs, hold in memory, reference for children. Gets tricky with complex graphs at scale.
Parallelization: Row generation is embarrassingly parallel, but writes are serial. Chunk-then-merge is on our radar but not shipped yet.
What does your stat product need, realistic distributions or pure volume/stress testing?
Why does this read like AI slop?
because it is, but its still true lol
does it handle skewed distributions? faker's always been useless for this - like, your test data ends up with everyone having 5 orders when real data is all long tail
Not yet, but you're the second person in this thread to call out distribution control as a gap. It's on our radar now. Thanks for the feedback.
I appreciate this product existing, but the row limits in each tier seem very constrained.
Thanks for the feedback! Honestly, we're still dialing in the tiers, what row limits would feel reasonable to you for your use case? Always helpful to hear what people actually need.
To be honest, I think 1M rows is starting point for any paid plan. Any data model of minimal complexity explodes fast, especially with cascading one-to-many relationships. If anything, it may make more sense to have a table-level, rather than a global, limit. Or put the limit on "trunk" tables.
That is a really good point one-to-many relationships blow up fast. The trunk table idea is interesting, would simplify how people reason about limits. Appreciate the feedback, genuinely helpful!
SQL Server support would certainly help you sell enterprise plans.
Noted, we've been focused on Postgres first but SQL Server keeps coming up. Appreciate the feedback.
how is this compared to https://shadowtraffic.io/
Different focus, ShadowTraffic is config-driven and optimized for streaming/Kafka workloads. We're schema-driven: point us at your DDL and we generate relational test data automatically. Less config, more just give me test data that fits my tables.
This is a great idea. I've thought about doing something similar! On the other hand, I'm not sure it's a business. Is this using AI?
The pricing seems extremely high for what's basically a call to https://github.com/faker-ruby/faker but that makes sense if it has to pay for OpenAI tokens.
(who knows though, plenty of B2B deals signed for sillier things than this - good luck, OP)
Thanks! To clarify, the core engine isn't AI. It's deterministic pattern matching, so it runs in milliseconds with no token costs. There's an optional "Story Mode" that uses AI for narrative-coherent data (like "a churning SaaS with seasonal trends"), but the base product is just schema parsing + smart type inference.
The difference from Faker: you don't write any code. Paste your CREATE TABLE, get data back. Faker is a library you have to integrate, configure field-by-field, and maintain as your schema changes. Different use case — more like "I need a seeded database in 30 seconds" vs "I'm building a test suite."
Fair point on pricing though, still figuring that out. Appreciate the feedback.