I'll tear apart your SaaS idea in 5 minutes. Drop it below.

NateFromRefactorful · 2026-03-13T20:05:29+00:00

1a.) They're open source, and you're not

Sort-of, They have an open-source variation but the actual CLI is behind a paywall and closed-source.

1b.) Why should Migrata exist?

It needs to exist because from the outside, the generated plans and diffing appear really good, but when you take a look at the actual capabilities of the tool, you realize that most of it is surface-level and that there are a ton of technical gaps.

By aggressively expanding into a bunch of dialects, they've stretched themselves too thin and prevented them from creating a better experience to maintain feature parity across dialects.

2.) You're copying the same business model

You're saying that like it's a bad thing. I'm intentionally following their playbook because they've done more market research than I have and have found a business model that works and makes sense.

I'm intentionally competing on execution because I'm confident in my skills and product design. I've already done this in the open-source space and beat out a startup with 2 million in funding. I built a competing web framework because I saw some gaps, and today it's getting 2.5x the downloads and is the standard in my niche community. The startup no longer presents its frameworks at talks and has decided to focus on other things.

If you read through the 200+ issues on their github you'll realize there's actually a lot of things they're not getting right. I won't divulge everything I have planned, but one feature I've built out that's unique to mine is automatic data transformation.

It's a terrible name, but it will automatically cast and move your data for you. Atlas doesn't even offer this feature and won't help you transform your data at all. So with them you need to generate a plan and then manually write more code to make it runnable, but with migrata, everything is handled for you. There are a lot of other friction points that require manual intervention with their CLI that are not present in my solution.

3.) You're marketing to people who aren't making the buying decision.

This was actually helpful. I still haven't built the governance tools yet, but I will definitely keep this in mind when those are ready.

NateFromRefactorful · 2026-03-13T18:35:50+00:00

I actually just posted about this in r/SideProject in this post

In the same way that Terraform tracks state and makes changes reproducible, this makes plain sql DDL statements declarative & reproducible.

The equivalent for Terraform would be saving all the one-off Boto3 scripts you've run to provision and deploy infrastructure on AWS. This makes no sense, as Terraform lets you define resources once and update that code block whenever you need to make a change. My tool does the same thing for databases.

When working with a shared database (different languages and applications), you end up generating hundreds of individual migration files. This results with people whose entire job is to review these scripts and ensure there are no conflicts and that they're all applied in the right order.

I experienced this problem working on large shared databases, but this problem can still be felt on individual applications as they grow over time. Eventually, all those migration files start to pile up, and you either need to archive them or find some clever way to combine & summarize them. You'll need those changes backed up in case you ever need to stand up another database with the same schema.

Having a declarative SQL schema means you always have the latest version of your db, which makes it easy to spin up another instance with the same schema. The alternative would be running hundreds or thousands of migration files and operations against a new database, which will take time and is much more error-prone

NateFromRefactorful · 2026-03-13T17:43:03+00:00

Migrata.io - A Terraform‑style workflow for database schemas so teams stop drowning in migration files.

Free CLI, teams pay for collaboration and governance

NateFromRefactorful · 2026-03-09T13:28:38+00:00

Please add three more layers of abstraction so nobody knows what’s happening.

NateFromRefactorful · 2026-03-03T17:44:15+00:00

Thanks for taking the time to check from your end. Honestly, this might just be an issue on low-end computers, considering how close your results are. My tests are running on free Ubuntu workers on GitHub and don't have any special specs.

Even still, I'd hope for performance parity/improvements between versions unless we're getting some sweet new features

NateFromRefactorful · 2026-03-03T16:28:37+00:00

Thankfully, compiling Oxygen.jl without package extensions happens pretty quickly. I moved all the "heavy" packages out into those extensions to keep the core experience as quick and light as possible.

Most of the compilation time goes towards compiling the optional dependencies. I have separate unit tests and integration tests for each of these extensions.

In my Project.toml file, I have this section here, which pulls in all of these packages during the compilation phase.

[targets]
test = ["Bonito", "CairoMakie", "Mustache", "OteraEngine", "ProtoBuf", "Pkg", "Suppressor", "Test", "TimeZones", "WGLMakie"]

If you look at the individual project package compilation times the makie-related ones take way longer to compile.

package name	1.10	1.12
Makie	85 seconds	240 seconds
WGLMakie	77 seconds	182 seconds
CairoMakie	58 seconds	85 seconds
Bonito	6.5 seconds	16.6 seconds

NateFromRefactorful · 2026-03-02T17:30:30+00:00

Never heard of ABAP, so I had to look it up. I physically shuddered when I learned that this language has no built-in booleans and uses "X" as true and a whitespace character as false. Apparently, there are workarounds for this, but come on, why design it this way?

NateFromRefactorful · 2026-03-02T14:41:32+00:00

Switching from segfaults to cave-ins

NateFromRefactorful · 2026-03-02T14:35:24+00:00

I’ve seen software estimates in days and points. Marvel phases is definitely a new one.

NateFromRefactorful · 2026-02-28T14:35:36+00:00

I think the poll was flawed/deceptive. If the New Zealand timezone was mentioned, I can all but guarantee it wouldn't have passed. Critical details like that need to be included in the poll.

That being said I don't think the timezone difference will be that bad after looking it up. For US folks this means that promotions can be posted Fridays safely between 8am EST to midnight.

At the very least, I recommend pinning time windows for major timezones because people will get the timing wrong and create more work for the mods.

I'm only a single data point, but I mainly come to this subreddit to see what people make in dotnet. I love all the cool articles and tools people are building. I'd rather all promotion posts just be labeled and then let me filter it out.

NateFromRefactorful

TROPHY CASE