At the moment, this is largely a rant. I’m kind of getting tired of this, and increasingly dissatisfied with the process of developing databases in general. That said, it’s not a problem with planning or plotting a database. I know that for sure. I actually enjoy the process of taking a data model or a relationship and plotting it out in SQL. I don’t have much experience outside of SQL, but I do have experience there, and that part is fine. I enjoy transforming a data model into something concrete and statically ensured. I don’t want that part to change.

What I’m really tired of is the workflow around it.

Friction in the current project

On the project I’m on right now, we’re using SQL Server. Between SQL Server itself being kind of jank, weird DACPAC dependencies, and a lot of random baggage, a rebuild can take around four minutes. A clean, normal build takes about three and a half. That difference isn’t huge, but the normal build doesn’t even guarantee success because of strange role and permission issues. I really don’t like that.

Publishing locally is worse. Updating an existing database to the latest version takes almost ten minutes, which feels completely unreasonable. I see no reason for that process to take that long.

Comparing to code-first migrations

I think a lot of this frustration comes from my earlier experience working with databases before this role. Back then, we were using Entity Framework code-first databases. That approach had a big advantage: migrations were generated for you, you could run them quickly, and you’d end up with a database that matched your data model very fast. I liked that a lot.

What I didn’t like was maintaining relationships in Entity Framework. It’s very difficult—or at least unintuitive—to accurately and rigorously reflect a domain’s data model in EF. It feels like something about the ergonomics there could be improved.

Wanting a database-free migration workflow

At this point, I almost want the experience of managing migrations entirely without a database running at all. I don’t want to deploy a previous version to a database and then diff it against a new version. The database shouldn’t be involved in that process.

What I want is to be able to look at a Git diff and have something say, “Okay, I know what changed here. I’ll generate a migration for this.” Maybe migrations are tracked with IDs, maybe timestamps—I don’t know exactly what the mechanism should be. I just know that the current state of relational database workflows feels subpar, and I’m getting tired of dealing with it.

I don’t really know what to do about that yet.