Love the tone of the post. Thought it was really funny.
As for the actual service itself, the clear disdain for Silicon Valley startup bs makes me want to use it for a small website that I will almost certainly never finish.
Then again, I’m 51% sure I could build a very similar service for cheaper. Then again, $5/month is pretty cheap. Then again, this is a brand new SaaS, and may not be around in a year. Then again, I have no users and no website and no one relying on me.
Oh don’t worry, it will definitely be around in a year, We are committed to giving our customers the best experience possible. I guarantee that IMGZ will be up and running for a long, long time, or until someone gives me two bucks and I “amazing journey” the entire customer base.
For a 12x price hike, I would hope to see some Serious Business features. Maybe you could provide a Satisfaction Guarantee. Or maybe Enterprise Support.
I write an “amazing journey” post detailing how the service is seriously definitely never getting shut down for at least three days and retire on a beach while you deal with the rotting service.
Many! I think I’ve seen “incredible journey” used with that one email program you had to wait in line to get, one of the post-Flickr photo sites, Vine maybe?
One thing I’ve read over and over is “don’t store your files in a database”. I assume there are caveats, and times when this does make sense, but could anyone care to make the case for why this is a good or a bad idea in this particular scenario?
In general: Storing files in the database generates a ton of IO load on the database server, which is usually already IO-bound. If your database is busy doing other stuff (unlike, say, IMGZ which doesn’t do anything else) that’s going to degrade performance.
On the flip-side, it’s terribly operationally convenient when you can backup a single database and actually have all your data, and having consistency between the data-store & the filesystem store is nice so you can’t refer to files that have been deleted / failed to upload / whatever.
Generally, considerations for files are different than for other data. E.g. you almost never need to filter files by actual contents, or sum them, or do any of the other things databases are good at, you just want to be able to store them, retrieve them and delete them. If you saved everything in a database, it would be more expensive, just because of the type of guarantees that you need for data, which you don’t need for files.
That means you’d unnecessarily be paying all the costs that are associated with what we normally want to do for data, but not need any of the benefits.
Sqlite did an analysis on this and found that for files under a certain size, it is actually faster to read them from a database (based on the database page size): http://0x0.st/iFUc.png
It’s a bad idea in this scenario. But you’re not likely to care too much at very low scale.
One solid reason to care is that in PostgreSQL the maximum “row” size is 16KiB. If you go over that then “the next” 16KiB goes into what’s called a “TOAST” table, which has access characteristics similar to a singly linked list. (So, 1 request for a 64KiB row will cause 4 queries to the storage engine and so on.)
Other characteristics of the TOAST table is that it compresses on input, which can quickly saturate your CPU.
You basically have three options with Postgres: you can put the file contents in the row, you can use the large object facility, or you can write the file to disk somewhere and store the path.
Putting the file contents in the row is simple, and is the only option that gives you for-free the notion that deleting a row will get rid of the content of the file. It has the disadvantages that others have discussed, although I don’t think TOAST is so bad for performance.
The large object facility is basically file descriptors in the database. You have to take extra care to remove them when you’re done with them, and most ORMs have poor support for it. I have never seen the large object facility used in the wild, and it’s not a tool I would reach for personally.
The third option is probably the best. The filesystem will always be better at storing files than your layer on top of the filesystem. But you have integrity concerns here (deleting a row does not cause the corresponding file to disappear), and you have to back it up separately from the database.
Not very often, usually on my site, and I wrote another IMGZ post recently (that lobste.rs didn’t like as it’s a parody of business), but my problem is that I don’t find inspiring topics to write about frequently. I most like writing when I can make fun of something I find ridiculous, and I guess there isn’t enough of that :P
EDIT: By the way, the “cancel subscription” section should now be active for you, I just deployed that code a few minutes ago.
Love the tone of the post. Thought it was really funny.
As for the actual service itself, the clear disdain for Silicon Valley startup bs makes me want to use it for a small website that I will almost certainly never finish.
Then again, I’m 51% sure I could build a very similar service for cheaper. Then again, $5/month is pretty cheap. Then again, this is a brand new SaaS, and may not be around in a year. Then again, I have no users and no website and no one relying on me.
Hmmmm.
Oh don’t worry, it will definitely be around in a year, We are committed to giving our customers the best experience possible. I guarantee that IMGZ will be up and running for a long, long time, or until someone gives me two bucks and I “amazing journey” the entire customer base.
I lol’ed ^_^
The CHEAPASS tier is actually $5 per year, or ~42 cents per month.
Still overpriced, if you ask me.
Oops, completely misread that
I mean you called it “pretty cheap” so there’s no going back now, expect a 12x price hike
For a 12x price hike, I would hope to see some Serious Business features. Maybe you could provide a Satisfaction Guarantee. Or maybe Enterprise Support.
I will add that to the backlog, which is a euphemism for “no”.
5€/mo is what the whole server costs stavros to run.
So he’d need at least 12 users to recoup his costs.
I think that may be treading too far into the dreaded “at-scale” territory for stavros.
Oh God and they’ll think they have the right to email me for stuff, what a hassle
Stavros, what did you use to create the architecture diagram? It is fantastic and I shared it with all my friends. Both of them.
Haha, thank you! Yes, I took the sample Cloudcraft diagram and customized it to the exacting specifications of IMGZ.
It looks like the McMansion Hell of service architectures.
I love it.
Why are you giving me ideas
It looks like https://www.cloudcraft.co.
I love your pricing page - those ‘our choice’ tags are such bullshit.
What, like somehow $999,999.98 isn’t the best value for you?
What happens if someone seriously wants the $999k plan?
I write an “amazing journey” post detailing how the service is seriously definitely never getting shut down for at least three days and retire on a beach while you deal with the rotting service.
What startup is the phrase “amazing journey” in reference to?
Many.
Many! I think I’ve seen “incredible journey” used with that one email program you had to wait in line to get, one of the post-Flickr photo sites, Vine maybe?
He throws a party… I mean… hires a lawyer and makes a Series-A announcement?
The “nine fives” gave me a long sweet laughter; thank you!
Oh this reminds me I have to take the service down today if I’m going to meet the guarantee, it’s been up too long
One thing I’ve read over and over is “don’t store your files in a database”. I assume there are caveats, and times when this does make sense, but could anyone care to make the case for why this is a good or a bad idea in this particular scenario?
In general: Storing files in the database generates a ton of IO load on the database server, which is usually already IO-bound. If your database is busy doing other stuff (unlike, say, IMGZ which doesn’t do anything else) that’s going to degrade performance.
On the flip-side, it’s terribly operationally convenient when you can backup a single database and actually have all your data, and having consistency between the data-store & the filesystem store is nice so you can’t refer to files that have been deleted / failed to upload / whatever.
Generally, considerations for files are different than for other data. E.g. you almost never need to filter files by actual contents, or sum them, or do any of the other things databases are good at, you just want to be able to store them, retrieve them and delete them. If you saved everything in a database, it would be more expensive, just because of the type of guarantees that you need for data, which you don’t need for files.
That means you’d unnecessarily be paying all the costs that are associated with what we normally want to do for data, but not need any of the benefits.
Sqlite did an analysis on this and found that for files under a certain size, it is actually faster to read them from a database (based on the database page size): http://0x0.st/iFUc.png
It’s a bad idea in this scenario. But you’re not likely to care too much at very low scale.
One solid reason to care is that in PostgreSQL the maximum “row” size is 16KiB. If you go over that then “the next” 16KiB goes into what’s called a “TOAST” table, which has access characteristics similar to a singly linked list. (So, 1 request for a 64KiB row will cause 4 queries to the storage engine and so on.)
Other characteristics of the TOAST table is that it compresses on input, which can quickly saturate your CPU.
Another way to say that is, “it will work, until it doesn’t.” Which is true of 100% of scaling problems. :-)
The nice thing about simple solutions is that they can be easier to adapt and extend later when needed.
Scaling problems are for amateurs, if I get too popular for my architecture I’ll just disable the signup page.
But that’s one customer too late - who are you going to evict to get out of scaling problem territory?
The one with the most images, obviously.
You basically have three options with Postgres: you can put the file contents in the row, you can use the large object facility, or you can write the file to disk somewhere and store the path.
Putting the file contents in the row is simple, and is the only option that gives you for-free the notion that deleting a row will get rid of the content of the file. It has the disadvantages that others have discussed, although I don’t think TOAST is so bad for performance.
The large object facility is basically file descriptors in the database. You have to take extra care to remove them when you’re done with them, and most ORMs have poor support for it. I have never seen the large object facility used in the wild, and it’s not a tool I would reach for personally.
The third option is probably the best. The filesystem will always be better at storing files than your layer on top of the filesystem. But you have integrity concerns here (deleting a row does not cause the corresponding file to disappear), and you have to back it up separately from the database.
I think the site is kinda shady, won’t let me cancel my subscription. I hope I’ll remember to retry later on. Kinda sus, ngl.
I can cancel it if you want. I really should write that code, it is pretty sus.
Hahaha. I’ve never experienced lobste.rs equivalent of a standup comedy. I simply had to try and say thanks.
So sad I couldn’t afford to pay the full price and rake in billions in dividends. :-)
Do you write often?
Not very often, usually on my site, and I wrote another IMGZ post recently (that lobste.rs didn’t like as it’s a parody of business), but my problem is that I don’t find inspiring topics to write about frequently. I most like writing when I can make fun of something I find ridiculous, and I guess there isn’t enough of that :P
EDIT: By the way, the “cancel subscription” section should now be active for you, I just deployed that code a few minutes ago.