4 ms·

DynamoDB being part of the AWS ecosystem is a massive benefit.

by seanwilson 10y ago

bonzini 10y ago
I like the way you spelled "lock-in". ;-)
- dijit 10y ago
  I dislike your sarcastic winky face, but I agree with the sentiment. Unless you plan on handing amazon your money forever, you should always steer for agnostic solutions you have the ability to host yourself. As much as it may not 'scale' if you manage to get a passive income with decent understanding of load, then purchasing hardware is almost certainly cheaper for you. Cheaper is good, it means more return so you can invest that income in your new project (and pay amazon for easy scaling again, if you want). But removing that ability not only locks you into their platform which may change prices at any time... it also means you can't move to self-hosting when the time is right and save quite a lot of money.
  - calsy 10y ago
    I dont believe you are locked in with AWS forever if you choose DynamoDB. It doesnt use a unique database model that no other DB supports. Its based on NOSQL and it should be simple enough (with effort of course) to export a DynamoDB document store to another NOSQL solution.
    - dijit 10y ago
      your reply makes me believe you've never migrated database solutions for larger projects, especially ones where you're trying to actually make money and spend little time. Migrating database solutions is really quite expensive in terms of time. I've done it twice and it's not something to take lightly. The usual recommendation is to never migrate database solutions unless there is a catastrophic problem with continuing with the current.
      - calsy 10y ago
        If you are talking relational database (I dont know, you just say databases), yes there can be issues exporting foreign keys, views you name it. But is it possible, yes it is. NOSQL database on the other hand, completely different scenario. Exporting is a much more steamlined process. Again, its not magic, there is effort, but it is possible. Just because you or your company are risk averse or strapped for cash, doesn't mean it's impossible to export a database. All the databases mention have export/import operations available, and as I said you are not locked into AWS if you do not wish to be. Oh and don't assume my history thanks, you know nothing of it.
        dijit 10y ago
        >Oh and don't assume my history thanks, you know nothing of it. I'm going to attempt to be constructive here, but of course I'm biased so please take it with a grain of salt. I cannot look past the words you speak, they are how I form an opinion of you on the internet. I cannot see your history, I cannot see your face/body language. Your words are your personality, they show your experience. What you've said reminds me of similar people I know who have a distinct lack of experience, so, I lump you into that category. In an attempt to understand you better I have peeked into your comment history. I can honestly say that I've not seen as much arrogance and bitterness for quite some time on hackernews. Instead of trying to be snide and assuming you're better than people, or trying to passive-aggressively "win" a conversation.. Why don't we try to extract as much understanding or knowledge from every interaction on HN as possible. most people on hackernews have some strong technical background, we have people here who are absolutely the forefront of their industry posting as regular users (Bryan Cantrill and Branden Gregg come to mind) which is absolutely humbling. Now, with that out of the way, I invite you to read the topic. "DynamoDB cannot store empty strings" contrast that to your comment >"NOSQL database on the other hand, completely different scenario. Exporting is a much more steamlined process." NOSQL solutions aren't comparable if they handle types differently, they suffer most, if not all, of the conversion problems of relational databases. The problem I faced when converting database solution was always types... Triggers, views and other relational-isms are a one-time investment fix.. converting types can easily lead to corruption of a few columns for a few rows.. how do you check that? The answer is writing a lot of tests, and doing things especially carefully and incrementally. and also, optimising for more revenue is not being cash-strapped, it's being wise enough to be able to reinvest capital in a new venture.. it's incredibly unwise to throw money up the wall for no reason other than it would cost a lot more to switch away due to vendor lock-in. (which is a reason not to move in of itself) which is what I'm warning about.
- seanwilson 10y ago
  It's a fair point, but when you stick to the same ecosystem you save a lot of time in terms of setup for credentials, monitoring, backups, devops etc.

DynamoDB being part of the AWS ecosystem is a massive benefit.

bonzini 10y ago

I like the way you spelled "lock-in". ;-)

dijit 10y ago
I dislike your sarcastic winky face, but I agree with the sentiment. Unless you plan on handing amazon your money forever, you should always steer for agnostic solutions you have the ability to host yourself. As much as it may not 'scale' if you manage to get a passive income with decent understanding of load, then purchasing hardware is almost certainly cheaper for you. Cheaper is good, it means more return so you can invest that income in your new project (and pay amazon for easy scaling again, if you want). But removing that ability not only locks you into their platform which may change prices at any time... it also means you can't move to self-hosting when the time is right and save quite a lot of money.
- calsy 10y ago
  I dont believe you are locked in with AWS forever if you choose DynamoDB. It doesnt use a unique database model that no other DB supports. Its based on NOSQL and it should be simple enough (with effort of course) to export a DynamoDB document store to another NOSQL solution.
  - dijit 10y ago
    your reply makes me believe you've never migrated database solutions for larger projects, especially ones where you're trying to actually make money and spend little time. Migrating database solutions is really quite expensive in terms of time. I've done it twice and it's not something to take lightly. The usual recommendation is to never migrate database solutions unless there is a catastrophic problem with continuing with the current.
    - calsy 10y ago
      If you are talking relational database (I dont know, you just say databases), yes there can be issues exporting foreign keys, views you name it. But is it possible, yes it is. NOSQL database on the other hand, completely different scenario. Exporting is a much more steamlined process. Again, its not magic, there is effort, but it is possible. Just because you or your company are risk averse or strapped for cash, doesn't mean it's impossible to export a database. All the databases mention have export/import operations available, and as I said you are not locked into AWS if you do not wish to be. Oh and don't assume my history thanks, you know nothing of it.
      - dijit 10y ago
        >Oh and don't assume my history thanks, you know nothing of it. I'm going to attempt to be constructive here, but of course I'm biased so please take it with a grain of salt. I cannot look past the words you speak, they are how I form an opinion of you on the internet. I cannot see your history, I cannot see your face/body language. Your words are your personality, they show your experience. What you've said reminds me of similar people I know who have a distinct lack of experience, so, I lump you into that category. In an attempt to understand you better I have peeked into your comment history. I can honestly say that I've not seen as much arrogance and bitterness for quite some time on hackernews. Instead of trying to be snide and assuming you're better than people, or trying to passive-aggressively "win" a conversation.. Why don't we try to extract as much understanding or knowledge from every interaction on HN as possible. most people on hackernews have some strong technical background, we have people here who are absolutely the forefront of their industry posting as regular users (Bryan Cantrill and Branden Gregg come to mind) which is absolutely humbling. Now, with that out of the way, I invite you to read the topic. "DynamoDB cannot store empty strings" contrast that to your comment >"NOSQL database on the other hand, completely different scenario. Exporting is a much more steamlined process." NOSQL solutions aren't comparable if they handle types differently, they suffer most, if not all, of the conversion problems of relational databases. The problem I faced when converting database solution was always types... Triggers, views and other relational-isms are a one-time investment fix.. converting types can easily lead to corruption of a few columns for a few rows.. how do you check that? The answer is writing a lot of tests, and doing things especially carefully and incrementally. and also, optimising for more revenue is not being cash-strapped, it's being wise enough to be able to reinvest capital in a new venture.. it's incredibly unwise to throw money up the wall for no reason other than it would cost a lot more to switch away due to vendor lock-in. (which is a reason not to move in of itself) which is what I'm warning about.
seanwilson 10y ago
It's a fair point, but when you stick to the same ecosystem you save a lot of time in terms of setup for credentials, monitoring, backups, devops etc.