I’m used to web frameworks that manage and run database migrations (e.g. Rails, Django).
I’d like my serverless project to have something similar, so that I can keep a directory of migrations and have the database run them during a deploy. (Caveat: I only think I want this because its what I’m used to. I’m all ears to other suggestions.)
The database I’m working with now is an RDS Postgres instance. Because my lambda functions have access to this RDS instance through specific subnet and security group, I’m thinking that what I might want is a lambda function that runs migrations.
Is this crazy? Is there some other recommended way to run migrations for Serverless apps?
I know we’re talking about this on Slack too, but I figure putting it here is good for everyone’s benefit…
Your “caveat” comment is on the right track - this is a pattern you’re used to from Rails/Django/et al, which doesn’t translate well to a Serverless (or server-less) environment well. I know because I came with the same patterns/ideas. The “problem” you’re trying to solve is a database problem - not an application problem - but using ORMs blurs the lines between the two. Remember, in the days before RAD (Rapid Application Development), migrations were the domain of DBAs, and developers never got a chance to do them!
Given how infrequent migrations are (or should be!) I’m a proponent of doing them from a management subnet/machine. While this breaks a “pure” server-less setup, IMO it’s the most sane approach. While I could imagine a solution to run your migrations with something like apex-shell or lambda-shell, I’m not sure I feel comfortable recommending them.
