Sometimes you're forced to use AWS for a very specific reason, technical or non-technical, subject to change in the future. (For example, literally being given a large 7 figure "credit" as occurred at a previous job.) Letting the application become completely and irreversibly dependent on [expensive] AWS services may not be desirable.
But who are we kidding... it's impossible to resist and its why AWS rakes in cash.
That said, not being able to use vDSOs for time querying APIs isn't just a problem for databases, it's potentially a significant problem for asynchronous software, like Node.js, that do userspace event scheduling bookkeeping. Typically every iteration of the event loop performs at least one time query, but depending on how the software is coded often there might be one or more time queries per event processed per event loop iteration.
There is no magic in PG itself, it’s just normal Postgres. You can dump and reload your data somewhere else.
But they provide management, point in time recovery, and other nice things. All done for you automatically. If you move you have to take that on yourself (if you don’t move to another provider that does it too).
Yes I understand that. But you still aren’t “locked in” you just have to manage more of the stuff yourself if you move from AWS. That’s kind of the point of using AWS.
It's one thing for an engineer to resist (or resist in principle). It's another thing entirely for an organization to resist. One team taking the expedient route can wed the organization to AWS forever.
It's how the mainframe and Windows ecosystems worked. Kudos to AWS for figuring out how to capture the exploding market for Linux- and OSS-dependent stacks.
Yes and no. I will say its depends on what else you are running on AWS. As long as you don't code yourself into a corner so it could be a right ball ache switching providers moving away from AWS shouldn't be too much of a problem.
Remember (not you but the people who made your comment dead) AWS aswell as every other provider want to lock you in.
I say this as someone who uses AWS. But their are things that still tick me off with the platform. As an example They don't make it easy to RDNS a light sail instance verses an EC2 instance so you want to RDNS to help with that outgoing email server you want to set up its easier to pay for a micro ec2 then use lightsail for the same purpose (which comes with included bandwidth and its an outgoing email server so its not like CPU is a major issue) or use SNS, but its more beneficial to AWS for you to use ec2 or sns even if its not to you because of your end of month bill.
Anyways my point is its possible to resist the AWS lock in with a bit of forward thinking as long as you code for the possibility that you might want to swap providers.
But who are we kidding... it's impossible to resist and its why AWS rakes in cash.
That said, not being able to use vDSOs for time querying APIs isn't just a problem for databases, it's potentially a significant problem for asynchronous software, like Node.js, that do userspace event scheduling bookkeeping. Typically every iteration of the event loop performs at least one time query, but depending on how the software is coded often there might be one or more time queries per event processed per event loop iteration.