DEV Community: Graham Sutton

Mockyard Update: Real Addresses Are Here

Graham Sutton — Thu, 18 Jun 2026 21:48:06 +0000

Quick update on Mockyard - the free, open source, self-hostable alternative to Mockaroo I wrote about a few weeks ago.

The Problem With Fake Addresses

I needed to test a CASS certification pipeline, which validates whether addresses are real and deliverable. Fake addresses fail that check immediately, so they were useless for testing.

I also didn't want residential addresses. If a bug ever slipped through and triggered a real mail piece, I didn't want it landing at someone's house. Non-residential addresses meant real, valid data without any of that risk.

Real Addresses, Now Built In

Mockyard now ships with 100,000+ real, non-residential US addresses you can generate against directly.

When you select the Real Address type, Mockyard maps each component - address_line_1, address_line_2, city, state, country, and zip - to separate columns automatically. You can rename any of them to match your schema.

You also get optional filters if you need to scope the data down:

States (e.g. CA, NY, TX)
Cities (e.g. San Francisco, Austin)
Zips (e.g. 10001, 90210)
Countries (just US for now)

The candidate pool updates in real time as you adjust filters.

A Few Notes

US only for now. I'll add more countries if there's demand - open an issue on the repo if that's useful to you.
Non-residential only. These aren't people's home addresses.
All rows unique — unless you filter. With no filters applied, all 100K addresses are available and all 100,000 rows will be unique. Filtering reduces the candidate pool, so if the number of candidates drops below the number of rows you're generating, addresses will start to repeat.

Repository: https://github.com/portside-labs/mockyard

As always, if you find it useful or want something added, open an issue. That's the fastest way to get it prioritized.

I made a free, open source, self-hostable alternative to Mockaroo

Graham Sutton — Wed, 13 May 2026 15:47:20 +0000

I created Mockyard - a free, open source, and self-hostable alternative to Mockaroo.

Mockyard ships as a Docker container that just runs:

docker run -p 8080:8080 ghcr.io/portside-labs/mockyard

Problem

If you don't know what Mockaroo is, it's an online tool for generating large amounts of mock data in formats like CSV, JSON, SQL, etc.

The catch is that Mockaroo is limited to 1K rows per file on the free tier, and costs $60/year if you want to generate files with up to 100K rows. It's also not open source and not self-hostable.

I built Mockyard for two reasons:

AI has made it possible to build things that used to live in the "I wish I had time for this" category.
I needed to test CSV ingestion pipelines with hundreds of thousands to millions of records, and I wanted something that was fast, memory efficient, easy to use, and didn't require going online or installing a bunch of languages, tools, or packages.

Now it costs me $0 to generate up to 10 million rows per file, every day of the year.

Honestly, I figured someone would have already built this, but either nobody actually has or I'm terrible at Googling.

And yes, I tried generatedata.com too. It's good, but it didn't quite fit the way I needed to generate some of my mock data.

Differences

One thing I wanted was the ability to generate data using weighted enums. In Mockyard, you can specify not just fixed enum values, but also their distribution.

For example:

20% of records should have role = Admin
30% should have role = Manager
The remaining 50% should have role = Viewer

Another issue I had was address realism. Seeing things like:

Miami, Yukon Territory, Switzerland

for city, state, and country combinations hurt my eyes.

So Mockyard supports lookup tables so fields can stay logically connected. If a city is selected, the state and country can match appropriately instead of being generated independently and producing nonsense.

You still have to specify your own lookup values, but at least the generated data looks realistic.

Performance

Initial benchmarks for the same CSV with four columns:

Rows	Format	Time	Throughput (rows/sec)
1,000	CSV	0.02s	~50,000
10,000	CSV	0.09s	~111,111
100,000	CSV	0.53s	~188,679
1,000,000	CSV	4.89s	~204,499
10,000,000	CSV	53.61s	~186,532

10 million rows is currently the max in Mockyard.

Anything beyond one million rows and Excel won't even load the whole file anyway (at least on Mac), so this should cover most real-world scenarios.

Web or API - Your Pick

If you want to generate data programmatically, Mockyard also exposes an API endpoint:

The UI actually uses the exact same API under the hood.

Output

Right now, output is limited to CSV and JSON.

Why?

Because I personally haven't needed anything else yet.

That said, if people actually find this useful and want support for additional formats, feel free to open an issue on the repo.

Repository: https://github.com/portside-labs/mockyard

Raw SQL Migrations Library

Graham Sutton — Fri, 13 Sep 2019 21:38:14 +0000

Where I currently work, we operate on a stack of mostly PHP and PostgreSQL. Our framework was written in ZF1 (it's legacy), and our deployment process for keeping our database changes version-controlled is quite tedious and complex.

Outside of work, I love using frameworks like Laravel and Rails and one of the features I really love from both of these is migrations. Since our legacy application at work doesn't have this concept, I started thinking of ways to take this modern approach and apply it to our legacy app.

Since we cannot convert our entire application over to one of these frameworks (it would be a major overhaul), I looked into some options like Phinx and Flyway for possible integration, but these options were not really compatible with our app (for various reasons that would deserve their own post).

At our company, we make very heavy use of PostgreSQL: complex procedures, triggers, views, multiple schemas, data warehousing, etc... we power everything on it. Many migration-type libraries usually have some abstraction layer that doesn't really support the full range of these database features. For example, Rails migrations are written in Ruby and then converted down to SQL before execution; same with Laravel and PHP. This isn't a bad thing, but these types of abstractions don't truly support the wide range of database features (particularly procedures) and are typically limited to just creating tables, indexes, and constraints.

So, I decided to task myself (for fun mostly) with trying to build a migrations library that would run on raw SQL, and lo and behold, I actually got a simple concept going! The underlying CLI is written in PHP, but you write and execute migrations in raw SQL.

I figured that maybe a lot of other people could get some use from such a library, and so I put it up on GitHub a while back but never really shared its existence with anyone. So today, that is what I am doing.

I am really looking for people who would like to help make it better. I think it's a good start, but I know a truly great tool isn't built by one person alone. Feel free to criticize, praise, or contribute!

Exodus Migrations Library: https://github.com/grahamsutton/exodus

Laravel's factory method, but for JavaScript.

Graham Sutton — Sun, 02 Jun 2019 14:40:08 +0000

When I became exhausted with trying to create tons of mock API data on the fly for my Node projects, I created a simple little script that would let me define the skeleton of the JSON structure I wanted without having to copy, paste, and modify each individual record.

This script is now available as an NPM package that does almost exactly what Laravel's factory method does except for JavaScript. It's lightweight and great for stubbing APIs in your Vue and React projects, too!

Link to the repo: https://github.com/grahamsutton/factory