Hacker News Reader

Comment by stevencorona | Hacker News Reader

I always thought that limiting by the "size" of the database in megabytes was unintuitive with the 5MB/25MB plans (how many bytes are in a row?)- pricing per-row is much more developer friendly.

I wonder how they'll handle someone doing something awful like storing images or blobs in the database, though.

View on HN

We've generally found that this sort abuse rarely happens. Generally developers utilize our services as they are intended. And it is much easier to release new services and watch for abuse than to pro-actively restrict them before-hand.

There is nothing wrong with storing blobs in the database - it is one of the data types. But a database is not a replacement for AWS S3 either.

If we did find someone abusively using the database - especially if it was affecting the overall quality of service - we would reach out to them directly to address it.

While I agree that the old plans were unintuitive, the new plan seems somewhat abuse able. How big can a blob be in PG?

1 GB. You can see the other limits here:

http://www.postgresql.org/about/

actually a lob can go up to 2GB. Byteas are limited to 1GB.

I store images and other binary data in the db all the time, when this is closely associated with data in the db and needs to be maintained together. Usually these files are store once, retrieve seldom. However for practical purposes I would not recommend going above a few megs on a bytea field. lobs are easier because you can seek in them, but access will never be as fast as it would be directly from the filesystem.

A row can be 400GB, so both size and row metrics make sense. I think that the size metric is likely helped tremendously by sane alerts.

http://wiki.postgresql.org/wiki/FAQ#What_is_the_maximum_size...

http://www.postgresql.org/about/ even quotes 1.6TB/row. Guessing it's under the two maximums of 1600 max columns, 1GB max/field (though they may not actually be compatible)

I disagree. By restricting the number of rows I think you're just going to end up with folks creating sloppy schemas specifically to avoid going over the limit.

  post.categories (varchar) = "1,51,78,84,100"

and other wonderful non-normalized approaches.

Hm. If you must do that, remember Postgres is guilt-free-SQL, so don't use a varchar, use the array type.

http://www.postgresql.org/docs/9.1/static/arrays.html

or hstore https://postgres.heroku.com/blog/past/2012/3/14/introducing_...

I like that you guys pointed out more efficient ways to do stupid things :)

Well, if the time it takes you to contort your application to work around our row limits is worth less to you than $9/mo, you're probably in need of both technical and financial advice.

I don't disagree nor do I use heroku, it's moot for myself.

I was just commenting how row-limitations were a very NoSQL way of enforcing data limits and inappropriate for an RDBMS.

Oh, you don't need to use Heroku to take advantage of Heroku Postgres -- it's available as a standalone service.

People willing to go to extremes to save a few bucks are probably not hosting on Heroku to begin with. This doesn't seem like a scenario worth worrying about.

10 million rows though is a high enough limit to make that unnecessary.

Of course any limit can be engineered against. When I was in college, the deli used to have a deal where you could get a baked potato with whatever toppings you wanted for $1.50 or something. one of the topings was chilli. So I would fill the container up with chilli so it was more like potato chilli..... After a while they started charging by weight because apparently this was a popular approach to this esp. for college kids who would rather cut food expenses and spend money on other things.

I find over-normalizing databases to be just as much of a problem. "Perfectly normalized" databases create extremely nasty join statements which can create just as much havoc as poorly normalized databases, especially once an ORM is thrown into the mix, which most will be using.

Make a horrible schema just to avoid ten dollars a month? Surely the time of most developers is worth more than that.

Give a person an limit and he will try to overcome it no matter how silly it is.

I actually agree completely. I was looking at hosting on Heroku and I ended up just figuring out how big the biggest possible row would be for each table and basically enforcing a row limit by myself. Having a predefined row limit saves me from re-computing this number when I change my schema.

Reply on news.ycombinator.com