Hacker News Reader

Comment by SMFloris | Hacker News Reader

So 400 writes per second is not exactly what I would think about when thinking about a "Production" environment.

For Google sized, obviously not. But lots and lots of production stuff will likely live quite comfortably in 400 writes per second.

True, until it isn’t? It’s quite a big gamble and a large lock-in.

What would the benefit be for choosing Sqlite over MySql?

Easy to scale distribution of files vs having to scale a db server.

Does mysql still risk eating your data? https://stackoverflow.com/questions/6158568/mysql-myisam-dat...

That's MyISAM. Nobody uses that engine for production without specifically choosing it and hopefully for a good reason.

InnoDB has been the default storage engine since 5.5, released in late 2010, so for over a decade.

And to be explicit: It looks like InnoDB is ACID compliant and crash consistent, so indeed this criticism appears out of date. Thanks for correcting me.

Yep, and even before 5.5, InnoBD was present (since the early 2000's IIRC), and is what most people chose to use for any production level deployment (MyISAM never even supported transactions, so people had to use something different when they got serious), it just wasn't the default engine until that point so you had to specify it in your create table statement or use a config setting to change the default.

MySQL 3.x was mostly just okay for simple website that didn't do much. (MyISAM is good for either extremely read heavy with few writes or vice versa, was very performant in those cases for the time)

MySQL 4.x added subquery support and InnoDB as a standard component, even if not the default.

MySQL 5.0 added cursors, triggers, stored procedures, views.

I think from about this point MySQL was fairly usable in place of some enterprise DB's depending on use case, and most of the essential features were there, even if not always the default.

MySQL started as a super easy to use and accessible DB, and slowly accreted enough enterprise level features to be able to compete in that field, but it's been in use successfully there for quite a while.

In comparison, my (super limited and possibly incorrect) understanding of Postgres's history is that they focused on stability and enterprise level features first, and then later added some things for more convenience. I think they aren't super different in capabilities now, at least for the core functionality most expect.

Do you frequently dismiss technologies for failings they fixed a decade ago?

When there are enough failings to generalize and the product is owned by a company that I feel is evil incarnate, I'm happy to dismiss them and then proceeded to not pay attention for a very long time, yes. In this case, it appears that this particular feeling may indeed have been fixed.

Well, first you can tune SQLite to get a 1000x speedup over 400w/s, without compromising safety too much. Second, the use case is small & local — I use it as an fprintf replacement.

Second, 400 concurrent users per second is a lot? If I had 400 users per second, with a 10 minute engagement time for 4 hours a day, I’d have ~10000 daily users. If they paid a monthly SAAS of 5$/user, I’d be making 600k$/year.

So… considering the implementation simplicity, that seems like a good trade off?

It's not that large of a lock-in, you can fairly painlessly move from sqlite -> postgres. They share a lot of commonality.

I have no experience moving from sqlite -> mysql, but I imagine it's only a bit more difficult.

But I agree with thechao's comments also.

I’d also add this is on a tiny vm, so not amazing, but more than adequate for a small website.

With no claims to suitability. Just back of envelope based on 400 write transactions per second.

-- Assume an employee filling out a form on a web site that takes on minute to complete.

-- Assume submits are randomly sent. (A bad assumption)

Per minute that's (1 * 60 * 400) 24,000 people submitting a form. Or over a million people submitting their form per hour. Nothing Google scale but enough for most any internal business application.

These are also likely just serialized commits per second. Parallelized non-blocking writes and/or using explicit micro-batching(SQLite supports batch inserts) and you'll be blowing most gov sites out of the water.

Definitely fast enough if you want to implement centralized crypto blockchain ;) /s

Reply on news.ycombinator.com