It's very strange to imagine that you'd host a DB in a conceptually local manner to application services. This couples things in a way that's very awkward for scaling. Even if you're not using containers, you almost never organize deploys this way outside of beta/dev environments.

And if you were to make such a decision, then you'd capture it in the closure required to run the code you built, so you'd sort of bake in the inclusion of those services into any deploy of your code, using Nix's philosophy.

Or am I misunderstanding you?

What I'm saying is that you should have a nix package for your application and one for your database server. Whether these run on the same machine or not is a question for how they're deployed, but it should be the same package that's pulled in by the production recipe and the dev recipe in any case.

So? This kind of service often sits on a different box anyway in production.

I'm not sure what point you're making. Are you saying it's not important to run the same version of all your dependencies in development as in production?

I'm saying that in production, your application will likely connect to a database on a remote machine, which may or not have the same version as the one you packaged and you use for local development.