Live data from Hacker News

Amazon RDS for PostgreSQL

aws.amazon.com

241–246 of 246 posts

Re: Amazon RDS for PostgreSQL

#241
Hmm, interesting development. But am I the only one to see a huge gap in services between Amazon and Heroku, and one which most certainly bodes bad for Heroku? Specifically, with Heroku's recent PG 2.0 service, their 'production grade' Standard plan ranges from $50 - $3500, but "Up to 1 hr downtime per mo." ?!?1! Huh, really, with up to an hour downtime /month, you couldn't be serious about the product that runs atop this tier - a non starter me any most other SaaS businesses. Heroku's cheapest "high availability option starts at $200/month, still with "Up to 15 minutes of downtime per month."... still, this is a concern for me...

Now, comparing to Amazon, their '1.7 GB memory Small DB, 1-year reserved, multi-region' is around $28/month (with storage & transfer for my app no more $35/ month). The equivalent Heroku plan, Tengu (1.7 GB mem) STARTS at $350/month!!! Wow, not I'm really rethinking my hosting platform.... Amazon looks more attractive, even if I have to do a bit of sys admin for my web server/cloud server.

Re: Amazon RDS for PostgreSQL

#242
post #23
post #8

I've heard about PostgreSQL and know that HN community raves about it, but am currently using RDS with MySQL. Does it make sense to migrate to PostgreSQL, I don't have a lot of data as I'm in the early stage? What are the primary advantages that PostgreSQL provides over MySQL? Any advise/pointers is appreciated.

Postgres actually cares about your data. Perhaps you mistakenly insert "2013-10-32" into a date column. MySQL will silently convert this to "0000-00-00" (!!). Postgres will raise an error. Perhaps you make an error in a transaction. MySQL lets you keep doing subsequent things in the transaction. Postgres treats the transaction as invalid and forces you to start over. Perhaps you want to add a column to a table that h…

Thanks for the updated list. It's been a LOOOOONG time since I compared MySQL vs PostGreSQL in detail (around 2001), but what I found at the time made me never want to look at MySQL again.

Understand, MySQL-ers, I know that your DB has been patched A LOT over the last decade, but running with something that did not support ROLLBACK (nor isolation), nor foreign key constraints???

That the MySQL team even thought they could call such a thing a database terrified me, and made me quite scared to ever trust their judgement. (viewing the comments for this article suggest to me that playing those odds was the right thing to do, as well, rather than simply "prejudice")

That, and at the time, PostGreSQL was supporting stored functions that fit anywhere in SQL statement syntax that the return type matched the needed expression type (scalar, vector/row, matrix/table), and could be written in a PL/SQL work-alike OR alternate loadable languages, while MySQL had no stored procedures at all.

That, and at the time (already), PostGreSQL supported OOP-ish "extension" tables that extended other tables with extra, specialized, columns. Rows in the specialized, subclass, table would show up in the generalized, superclass, table (sans extra columns), but the subclass table would only show the relevant specialized type rows, with non-null columns where needed. Other DBs required you to join 2 tables and manage joins and a view to do this.

Putting SQL syntax on top of an ISAM engine just makes it dBase with awkward syntax, and that's not an environment I wish to revisit. (I know that InnoDB is constantly twiddled to suck less, but that back-end was extra back in the day, yes?)

Re: Amazon RDS for PostgreSQL

#243
post #4

This is HUGE! I'm using the AWS stack for http://www.soundslice.com/ and I've been using MySQL instead of Postgres, purely because my hatred for MySQL is less than my hatred for being a sysadmin. It was a tradeoff, and I miss Postgres dearly every time I use MySQL. This new Amazon offering solves that. I wrote a little more about my AWS setup here: http://www.holovaty.com/writing/aws-notes/

Good to see another Django creator. We are a proud django startup @kipinhall I couldn't believe my eyes when I read RDS Postgres offerings.

Re: Amazon RDS for PostgreSQL

#244
post #142

Earlier quoted context omitted.

I wasn't calling Heroku a monolith because they're a huge company -- it's because they suck you in & then youre forever stuck in their web of services. I bet they start bleeding a lot of money now that there is an easy-to-use alternative for Postgres hosting on a well-known platform. Heroku epitomizes the idea of overcharge + vendor lock-in & people only put up with their high prices because they don't have the time…

Just like AWS, you pay Heroku to simplify your system administration. You don't have to like Heroku's product but there is a place for it. I do not use Heroku but it makes total sense if you have an app you need to deploy and you don't know system admin, don't want to do system admin yourself, or can't afford a system admin. GitHub just "wraps up" git and charges for it and I am happy to pay them. Setting up a git se…

you could always use gitlabs or phabricator and you get much of what you just said is a PITA.

Re: Amazon RDS for PostgreSQL

#245
post #34

Earlier quoted context omitted.

You can be sure that that will come.

Probably not. Amazon has intentionally crippled external replication in MySQL for years now. It's a form of vendor lock-in and you shouldn't support it. Without replication it's impossible to migrate out of RDS without taking downtime (I've been through this and it was painful).

This isn't true anymore. RDS now exposes an external replication stream for Mysql. AWS actually doesn't seem to be that interested in vendor lock-in. They usually build what people ask for.

Re: Amazon RDS for PostgreSQL

#246
post #239
post #238

Earlier quoted context omitted.

This is almost the complete opposite of vendor lock-in. Vendor lock-in is when you write your software on Oracle or MSSQL and moving away requires you to rewrite your whole thing. It's not losing the convenience of "got push" for deploys and having to spend time moving off their hosted versions of open source software and configuring and hosting it yourself instead. Accusing Heroku of practising vendor lock-in is hon…

IMHO vendor lock-in is anything that makes part of your work process specific to a given vendor. The harder it is to move from one vendor to another, the deeper you are "locked in". And as a point of interest, I think these days its probly much easier to convert your database than it is to switch hosting platforms (well... in some cases).

We started off on Heroku because we wanted something dead simple. The amount of time heroku saved us was an incredible value when we were starting out. I don't think there is any vendor lock in. We just did not switch to AWS earlier because our needs were met really well by Heroku and even Amazon Elastic Beanstalk (for ruby) did not come near the ease of a Heroku deployment. Once Opsworks came around, we invested in deployment scripts and switched because Opsworks gives us same ease of use and greater control of our stack.

What do you think stops you from switching? We had no issues at all - definitely none from Heroku.

We still use PostgresSQL from heroku because it is still a solid service and comes with niceties like dataclips. I should confess that I have not explored the Amazon PostgreSQL offering but I am happy with Heroku for databases at the moment.

Post reply on HN