I think we are getting close to the peak of "declarative"—or rather, I hope we are near the peak.

In my experience, declarative APIs are very powerful abstractions for specific cases where finding the path to the declared state is better left to a machine. This is seldom the case - in most cases, offering the programmer control over the changes leads to better behaviors.

Kubernetes and IaC tools lead the way to a declarative state of infrastructure and these add a ton of value. But, they were also incredibly hard to build - it took many years before Kubernetes eventing and control loop abstracts were rock solid. Most CRD-backed implementations suffer from tons and tons of bugs, and most CRDs are not declarative - they abstract away an imperative operation! I guess this is nothing new - "anything in excess is bad".

Anyways, I think an imperative approach offers much higher control and predictability at a lower cost. The world inherently is imperative.

>In my experience, declarative APIs are very powerful abstractions for specific cases where finding the path to the declared state is better left to a machine. This is seldom the case

I've been waiting for this top comment for longer than you can imagine. The declarative madness has always bothered me. Sometimes it's easier to maintain when you see the process. And harder to declare the final state. It might look neat, but maintainability beats neatness every day.

I mean they just reinvented Prisma and Django

Yes, although the article isn't claiming to have invented declarative schema management. They're just saying it is now available as a feature in Supabase. (Personally I think that's great!)

Regarding prior art: Django migrations are indeed declarative, and were very early in this space. But they're tied to Python model definitions in the ORM, which is a bit more of a special-case than the native SQL CREATE based approach described here.

As for Prisma Migrate, they directly copied several innovations from my tool Skeema [1] which has been available since 2016, so they can be equally accused of "reinventing" things :)

Not that I invented pure-SQL declarative schema management either, by any stretch. I was largely inspired by the workflow at Facebook, who adopted declarative table management company-wide back in ~2012. FB found that having a declarative reconciliation loop is an operational necessity with a massively sharded system, given some hardware just dies every day. And centralized SQL-based schema management is advantageous when applications are written in many different programming languages.

[1] https://github.com/skeema/skeema

Any plans to add Postgres and SQLite support?

Skeema will always be specific to MySQL/MariaDB, but I hope to eventually release a separate tool which is more generic and modular. That's still a long while away though.

There are some existing declarative tools for Postgres and SQLite though, see https://news.ycombinator.com/item?id=43576450

Hi Peter, Thank you for doing this!

I'm on H-1B with an approved EB-2 via my current employer and an approved EB-1A (self-petition). I want to switch employers or take a break. I expected my priority date to become current in Q3 or Q4 2025.

Questions

1. If I switch to an H-4 status for a break, can that affect I-485 via EB-1A?

2. I need to visit family urgently and I have got a few offers in hand. Can I quit and travel internationally while the H-1B transfer is in progress and re-enter the US? My stamp expires in 6 months and my partner can mail the approved I-797. What are the general risks here apart from the mail getting lost?

3. Can a change of employment lead to issues with an AOS application in the future using EB-1A?

My responses in order: 1. Green card applications are prospective in nature, meaning they concern what the applicant will do after getting a green card so what an applicant is doing now, before getting a green card, shouldn't matter strictly speaking but switching to H-4 and stopping work could cause USCIS to question whether you intend to work in your EB-1A field after getting your green card. To be clear, however, the risk of this is low and USCIS's concern if raised easily rebutted. 2. Yes but you would need the original receipt or approval notice (combined with your existing visa) to get back in. Make sure to speak with the company's attorney about this/travel. 3. Unlikely, since the EB-1A isn't based on a specific offer of employment but as noted above, a change to a different field could raise questions about whether you will continue to work in your EB-1A field after getting your green card. To be clear, however, the risk is low that a job change in the EB-1A context would trigger an RFE by USCIS.