Hacker News Reader

Comment by m_mueller | Hacker News Reader

Aurora is I think pretty simple to move away from, since it's just fully compatible Postgres or Mysql. We even use a local postgres for development purposes against an Aurora solution.

View on HN

Nope. AWS makes it dead simple to move from RDS to Aurora by clicking a button. There's no way to move data from Aurora to RDS short of doing a SQL dump and reloading everything that way. I found this out when my previous employer was looking at moving from RDS to Aurora.

> > Aurora is I think pretty simple to move away from, since it's just fully compatible Postgres or Mysql. We even use a local postgres for development purposes against an Aurora solution.

> Nope. AWS makes it dead simple to move from RDS to Aurora by clicking a button. There's no way to move data from Aurora to RDS short of doing a SQL dump and reloading everything that way. I found this out when my previous employer was looking at moving from RDS to Aurora.

I got a bit of a chuckle out of this. There's no way to move from Aurora to RDS short of... 2 minutes of actual work and a lot of waiting around due to the limitations of the hardware?

I get that it's not as easy as a literal button click, but this isn't vendor lock in.

What if you have a really big database? Still 2minutes?

I'm intentionally ignoring any of the sarcasm in your comment. The time needed for a db dump is always dependent upon the amount of data. This is true regardless of the db software or where it's running.

I can't think of any project I've worked on where the main data base could be backed up and restored to a different database in "2 minutes"

The sarcasm was warranted.

With SSO multi-account and 2FA, it'd probably take longer than 2 minutes just to authenticate and configure AWS correctly to get started.

Isn’t the suggestion that the “active work” is very little and most of the time you’re just waiting?

Well, the elapsed time is how long I need production to be offline so there are a few more people "just waiting"

Sure, but you don’t really expect to swap databases with a huge data store without any downtime, do you? I’m not aware of any technology that makes that easy.

Then why are you defending the ridiculous "2 minute" thing?

If the CEO asked how long a migration will take would you respond "2 minutes of engineering time"?

In that situation I would guess the one-click tool doesn’t really handle everything you’d need either so I don’t get what the point of the comparison is.

I’m not the person would said it was two minutes.

Nor am I but if we go back up the claim was that they were making it much easier to get in than get out, but unless you're telling me that the one-click tool somehow solves all the issues of migrating a large production database that's in use the difference between the two is a minuscule amount of active work.

If you were the CEO and your engineer and someone said, "2 minutes of actual work and a lot of waiting around due to the limitations of the hardware", would you interpret that as "2 minutes of engineering time"?

Obviously I'm going to spend a lot more time communicating the details of the situation to the CEO of a company that is paying me, than I'm going to spend communicating in a Hacker News comment. But as it turns out, no amount of communication is going to be effective if people don't bother to read past the first opportunity they see to jump in with a correction, even if that means stopping reading mid-sentence.

Why would you take production offline to swap databases? Elapsed time is how long you need to run the new database alongside the old one.

This whole thread is about incompatible databases. If you know a 2 minute solution to a live transfer in that situation I’m all ears.

If only you had read the whole sentence, you might have saved yourself a bit of righteous anger.

I think you've failed to consider how impractical even doing a SQL dump can be on a large-ish database, forget about the reloading time.

I haven't failed to consider that, you've just failed to read where I explicitly mentioned that.

Consider: is that impracticality caused by Amazon creating vendor lock-in? Or is that impracticality caused by the fact that reading terabytes of data from storage, transferring it over the network, and writing it into storage is inherently slow because of the physical limitations of hardware, no matter what vendor you're using?

It's a bit odd for me to be in the position of defending Amazon here. I genuinely don't like them, don't use them, and generally do think they're guilty of creating a lot of vendor lock-in. But this is legitimately not an example of any of that.

I didn't miss where you mentioned it. I missed where you considered it. As in, you know, gave any thought to the practicalities involved.

You're really claiming you can read my mind to know what I have and have not considered right now, despite me bringing it up specifically. Alrighty then.

I'm simply going by what you've written here. If you have considered it, then you have not "shown your work," so to speak.

And if I were being graded that would matter.

As is, I've no responsibility to show you anything, and you're just making unwarranted assumptions about what I have and haven't considered, based on a pretty selective reading of what I've said.

You seem to be the one angry here.

I'm not sure what I was supposed to take away from your cryptic sentence. Is there a two minute solution to this problem that you are smugly keeping to yourself so you can mock people replying to you?

My guy, read this whole sentence, which has remained unchanged this entire conversation:

"There's no way to move from Aurora to RDS short of... 2 minutes of actual work and a lot of waiting around due to the limitations of the hardware?"

You seem to be having trouble getting past the word "and", so I've helpfully italicized the part you've repeatedly missed or ignored.

Now sure, that's a bit vague, but if you want more details it might have been advisable to ask a question rather than simply ignoring half the sentence because you don't understand it and jumping in with a correction.

And honestly, even if it's vague on some details, there's no universe in which "2 minutes and a lot of waiting around" = "2 minutes". Whatever vagueness you might accuse me of, that fact isn't vague.

hey,

that is fair answer! AFAIK, there are two things that consider:

* Aurora do have some vendor-locking feature if I'm not wrong?

* moving from Aurora to PostGres will lead to downtime of 2 minutes + unknown waiting, where this is not a case when you convert from PostGres to Aurora.

Kinda depends if you can run replication from aurora to regular database

Aurora Postgres supports bog standard native Postgres logical replication.

Oh, cool, I wasn't aware you could replicate from Aurora RDS to Postgres RDS. That reduces the risk.

Yes, still "2 minutes of actual work and a lot of waiting around due to the limitations of the hardware" which is what I said. Perhaps try reading the whole sentence next time?

If you can't stream changes and have to take downtime for a migration then you effectively have vendor lock in if you are serious enough about your database.

Physical Replication should be something any database can offer given its something cross database migrations used decades ago with no problem.

If you talk about no vendor lock in, and you'd want to take your database then to a competitor, like Google Cloud, Azure, or on-premises, wouldn't you exactly expect to do a SQL dump and reloading everything? To me, the one-click move from RDS to Aurora you describe is a nice shortcut, but it doesn't invalidate that you can still do the former if you wanted to move to the competitor. Vendor lock in seems more that you've architected your application against a system that only exists on AWS, like SQS or S3 (although, I guess, competitors offer compatible APIs for some of those, I'm not entirely read up on the state of things there).

Seems a bit of a dark pattern to have shortcut to onboard and not offer the same shortcut to offboard.

Just like easy subscribe-online publications that will have you call during 2 hours with a rep pushing you discounts or whatever to cancel such subscription.

Just not cool

I'd characterize this asymmetry (convenient shortcut IN, standard export OUT) as a predictable, transparent, minor annoyance -- not a "dark pattern" representing deceptive or unethical practices.

OK. yeah maybe dark pattern was a too strong term for just the annoyance...

Just I'd try to stay away from amazon if I could

This can be done with DMS. https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introd...

Huh. I suppose you can. The pricing looks a little opaque though, and the fact that it took 3 hours after I wrote my comment for yours to show up kind of implies it's a bit of an obscure service.

I will also mention that the AWS team we were working with on this didn't mention DMS, and, when directly asked, literally told me there was no easy way to do an Aurora -> RDS migration.

Which is weird. This has been around for a few years, and, at least I thought, was a fairly popular service.

Previously it wasn't great, but since they started using Logical Replication for Postgres, it's gotten far better than it was in the past.

Aurora significantly modifies the internals of the DBs, particularly the storage layers. It also makes large changes to how memory is used for Postgres. Query plans can be quite different than with the vanilla version. Once you tune and create indexes based on Aurora's characteristics it's going to be a pain to retune for the unmodified version. Aurora also introduces nasty bugs that don't exist on the RDS version such as a memory leak I found was periodically restarting our master. The Postgres team produces highly reliable code, but I don't trust Aurora's hacks on top of it.

thank you! I needed to read this!

Reply on news.ycombinator.com