Startups should use a relational database

Re:Startups should use a relational database by pkolaczk on Sunday December 22, 2013 @05:55AM (#6949983)

For the startup I once worked for, it mattered much more than we had thought at the beginning. The investors were smart enough to notice we had some considerable periods of downtime. Additionally, once we got first million of users (not really that much and nowhere near the scale of Google or FB) we ran into performance problems which couldn't be easily solved just by indexing, optimizing queries or adding more hardware, and "buying" a beefy Oracle superserver was not an option as we didn't have enough revenue yet. So we had to dump joins, relax transactions, denormalize a lot and ended with a half-baked, bug-ridden NoSQL store on top of PostgreSQL, that couldn't even do horizontal partitioning well. I wished we had a proper solution like Cassandra right from the start. It would save us lots of pain.

[ Parent | on HN ]

Re:Startups should use a relational database by coolsunglasses on Sunday December 22, 2013 @07:13AM (#6950109)

First million users. Come on. 99% of your audience is never going to have that problem.

Especially if they spend their early days fucking with a Cassandra cluster instead of talking to customers.

And it should be noted, you made it anyway.

When you make it by the skin of your teeth, that means you probably timed it right.

Preempting a problem far-ahead of time in startups means time and effort was wasted, especially if it was done before the existence of the problem was established.

It is unreal to me that people still can't figure out how to apply Maslow's hierarchy to startups.

[ Parent | on HN ]

Re:Startups should use a relational database by pkolaczk on Sunday December 22, 2013 @07:47AM (#6950151)

A million registered users is nothing for an MMORPG. You can get it pretty quickly even in a national-level game, without going global. A completely different story is keeping those users active and earning on them. The problem here is - you need to sustain a pretty massive load, yet only a few % of that load brings you revenue. And things like being out of service for even 10 minutes during peak hours (and peak load can be 100x higher than average load if you do special events in the game) can put you out of business or at least seriously worry potential investors.

The sad thing is they actually didn't make it. I don't think the revenue ever crossed the cost of f*ing with all the scalability and availability problems. AFAIK currently they use Membase.

[ Parent | on HN ]

Re:Startups should use a relational database by coolsunglasses on Sunday December 22, 2013 @02:35PM (#6951383)

A million registered users is $15,000,000 a month if you're charging $15 a month, which was standard for a long time.

Are you fucking serious? A product that fails with a million users has a monetization problem not a technological one.

[ Parent | on HN ]

Re:Startups should use a relational database by pkolaczk on Monday December 23, 2013 @03:47AM (#6953615)

Not in the freemium model. In the freemium model it is easy to get many registered users because you're giving the basic version of the game for free and charging for extras. And if 10% of users pay for some extras at all, you may consider yourself very lucky. Typical paying users share is 2-5%. Another problem is 1 million of those users don't play all the time (we had only 5% of them logged at a time), however it is possible to get most of them active for a short time by organizing special events / competitions for them. Therefore you need to have capacity for handling that 1 million of users for a very short period of time, therefore you need to scale, but you are not going to make money from them constantly.

[ Parent | on HN ]

Re:Startups should use a relational database by pkolaczk on Sunday December 22, 2013 @12:19PM (#6950847)

Additionally, when you do a startup and it succeeds it is already too late to redesign your app completely to make it scale. Changing the RDBMS in the middle of the game and migrating data is risky and would cost you probably more than using a properly scalable database right from the beginning.

Additionally once you know you need to scale, your competition will see your product. Knowing the idea works, if they start from scratch, but using a better database for the job, they can easily put you out of the business, because instead of competing and adding new feauters, you'll be busy fighting scalability problems.

[ Parent | on HN ]