Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon RDS for PostgreSQL

aws.amazon.com

Post reply on HN
Print view View original

231–240 of 246 posts

Re: Amazon RDS for PostgreSQL

#231

Post by chrismmccomas »

dangrossman wrote: post #109
LVB wrote: post #108

I've only ever used S3, but some of these AWS offerings do look interesting for my little projects. My question is, how do hours get calculated for billing? If I had my super low traffic blog using RDS, would I incur a few microseconds of time per DB hit, or is it rounded up to an hour, or is it the total time the DB is available period?

You would be paying for 24 hours each day. You are renting a managed virtual server, and you pay for each hour this server is running in addition to usage fees for storage and IO operations when it's actually being accessed. It'd be $20-30/month to host the database for a very small blog.

To be fair, if you qualify for the AWS Free Usage Tier, you could run a small blog with RDS for $0 for the first year.

Re: Amazon RDS for PostgreSQL

#232

Post by kisstheblade »

oceanplexian wrote: post #184
Sssnake wrote: post #178

Earlier quoted context omitted.

That is absolutely ridiculous. Less than 1% of 1% of mysql users are using replication. Suggesting it is a "total non-starter" for most production uses is crazy.

You're kidding right? I'd wager that a huge number of MySQL users are using replication. Running a single database in a production environment is totally unacceptable and a major business continuity problem.

" Running a single database in a production environment is totally unacceptable"

What hyperbole. I've been running mysql in production for over 15 years over almost a hundred projects, almost always on a single server without any replication. Never had any issues with it. Shame I can't down vote yet.

Re: Amazon RDS for PostgreSQL

#233

Post by eli »

e12e wrote: post #227
jacques_chester wrote: post #206

Earlier quoted context omitted.

I run a small Wordpress network. MySQL's insistence on going to disk for joins on tables with a TEXT field (even if the query doesn't touch those fields ) is probably the major performance bottleneck.

Ouch. Thanks for the explicit heads-up. I generally stay with PostgreSql, but I honestly thought most of these things were "fixed" in recent versions of MySQL (and assumed my subconcious dislike of MySql was at least partly irrational/rooted in Ancient and Outdated Lore). I guess not: http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-ta... I'm not sure what the status of TEXT-fields are in mariadb: https://ma…

I tried MariaDB about a year ago and it had the same problem. It's possible it's been fixed since. I personally prefer the Percona fork of MySQL, which has some performance tweaks yet is basically a 100% drop-in replacement.

Re: Amazon RDS for PostgreSQL

#234

Post by jacques_chester »

e12e wrote: post #227
jacques_chester wrote: post #206

Earlier quoted context omitted.

I run a small Wordpress network. MySQL's insistence on going to disk for joins on tables with a TEXT field (even if the query doesn't touch those fields ) is probably the major performance bottleneck.

Ouch. Thanks for the explicit heads-up. I generally stay with PostgreSql, but I honestly thought most of these things were "fixed" in recent versions of MySQL (and assumed my subconcious dislike of MySql was at least partly irrational/rooted in Ancient and Outdated Lore). I guess not: http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-ta... I'm not sure what the status of TEXT-fields are in mariadb: https://ma…

> Thanks for the explicit heads-up.

It took me a long term to learn this one. I suppose if I'd read the MySQL docs from cover to cover I would've found it earlier.

One other problem that popped up was ignoring indexes on tables with TEXT fields during joins, which was a planner weakness. I understand it was fixed in 5.6; I'm waiting for the Percona version to stabilise before I upgrade.

Re: Amazon RDS for PostgreSQL

#235

Post by eli »

avenger123 wrote: post #144
fat0wl wrote: 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…

Fair enough. Looks like not a lot of love for Heroku for you. This could be a nice fire under Heroku's ass to get more competitive.

Hard to compete with your main supplier, no?

Re: Amazon RDS for PostgreSQL

#236

Post by catch23 »

fat0wl wrote: post #197
kennystone wrote: post #170

Earlier quoted context omitted.

This is not true at all. Apps on Heroku are built on open source software (Rails, Postgres, etc). You can always decide to host it all yourself without too many issues.

How is this not true? It absolutely IS vendor lock-in, just in a slightly less sinister form. If you add 5 services & then to switch hosts it's not another git push. You have to re-configure each of the services. If you'd done this yourself all along & made machine images it would have been less convenient at the time, but probably cheaper & a good learning experience. There are many other hosting platforms that offe…

Heroku is great for clients though. When I was a freelancer, I built these apps for other companies that assumed that I would do the admin & hosting. Heroku is great way to just "tack on a fee" for doing the hosting. If they want a cheaper option, they can always do it themselves. Most clients don't care about the savings on hosting..

Re: Amazon RDS for PostgreSQL

#237

Post by billmalarky »

will_work4tears wrote: post #191
elob36 wrote: post #103

Earlier quoted context omitted.

To me, the MySQL query optimizer (single index in a query) was the proverbial straw that broke the camel's back. My group is developing all new applications in PostgreSQL and we would like to migrate our legacy apps away from MySQL.

I'm on mobile and cant quickly and easily search this but is there a good GUI for postgre similar or superior to phpmyadmin?

Check out Navicat and you will never touch phpMyAdmin again.

Re: Amazon RDS for PostgreSQL

#238

Post by simonw »

fat0wl wrote: post #197
kennystone wrote: post #170

Earlier quoted context omitted.

This is not true at all. Apps on Heroku are built on open source software (Rails, Postgres, etc). You can always decide to host it all yourself without too many issues.

How is this not true? It absolutely IS vendor lock-in, just in a slightly less sinister form. If you add 5 services & then to switch hosts it's not another git push. You have to re-configure each of the services. If you'd done this yourself all along & made machine images it would have been less convenient at the time, but probably cheaper & a good learning experience. There are many other hosting platforms that offe…

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 honestly absurd.

Re: Amazon RDS for PostgreSQL

#239

Post by fat0wl »

simonw wrote: post #238
fat0wl wrote: post #197

Earlier quoted context omitted.

How is this not true? It absolutely IS vendor lock-in, just in a slightly less sinister form. If you add 5 services & then to switch hosts it's not another git push. You have to re-configure each of the services. If you'd done this yourself all along & made machine images it would have been less convenient at the time, but probably cheaper & a good learning experience. There are many other hosting platforms that offe…

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).

Re: Amazon RDS for PostgreSQL

#240

Post by Sssnake »

jeltz wrote: post #224
Sssnake wrote: post #200

Earlier quoted context omitted.

>Using a single, unreplicated database instance in production for anything serious is bizarre It is incredibly common. Go check out a thousand businesses running mysql, you'll be able to count the ones using replication on your fingers. >Failed hardware is hardly unheard of. You don't need to use mysql replication to deal with that. Even the crappiest low end SAN storage devices do it vastly better than mysql does, w…

I have heard stories of entire SANs failing so I would not advice trusting your SAN too much. For example there was a huge outage at a Swedish host caused by a failed SAN, all data was lost so people had to use daily backups to restore. Replication can be done off-site so you at most lose a couple of seconds worth of data. I do not know anything about MySQL's replciation but my trust in PostgreSQL's is very high.

>I have heard stories of entire SANs failing

Which is why it is being replicated, like I said.

Post reply on HN