Hacker News Reader

Comment by hasenj | Hacker News Reader

I really don't understand why majority of websites use mysql or even postgres for that matter. The vast majority of websites would run perfectly fine on sqlite.

Not only would you get rid of network latency, you would also vastly reduce your dependencies.

I have a side project to try to see if I can build a minimal micro-blogging type server application on sqlite and try to test how many requests it can handle per second (reads and writes).

I have a hunch it will be able to handle quite a lot. Specially if the server code is written in a fast language that compiles to native code (e.g. D) with some caching of the most commonly requested items in memory.

View on HN

Concurrent writes is a problem since the locking is at database level[1]. For a small to medium-low website might be OK depending on the writes volume.

[1] https://www.sqlite.org/lockingv3.html

As the header of your page denotes, things got significantly improved years ago with the addition of a WAL as the default mode rather than an exclusive write lock.

Also, I think most websites don't even need constant access to the DB, because the data doesn't change often.

Compile a static site from SQLite when someone enters new data, push it somewhere to be accessible and be done with it.

I'd be willing to bet that 99% of the sites/apps on the web have low to medium writes and reads. Developers like to plan on needing Facebook and Uber scale for their new task list and subscription box services though. SQLite benchmarks are impressive, they beat out commercial RDMS in a lot of comparisons.

Network latency is only really a problem if you host your db on another machine. An Unix socket has something like 1ns. As for dependencies, the package manager takes care of that.

  > An Unix socket has something like 1ns.

That seems implausible, given that you're lucky to get a context switch down to 1µs if the cache gods smile on you.

Sorry, I meant 1 microsecond.

With the complicated aws-based deployment schemes people are using these days, what's the chance that the db is on the same machine?

SQLite does not work smoothly in many languages (like python) in regards to concurrent access. Without a controlling process (or thread) it's synchronisation possibilities are limited, so it can never scale too far.

Nonetheless I think it's a great idea to build your own single-threaded layer over SQLite and scale that, using a message bus or whatever.

But it's _not_ a drop-in replacement for MySQL based apps.

SQLAlchemy with transactions on SQLite should get you very close, probably close enough.

Why get very close when I can just spin up a single micro RDS instance of MySQL or Postgres and not have to worry about it?

Whoa! That's nearly $20 a month, if you're past the free tier, which you will be if you're not already. Edit that's t1.micro, t2 is $13.

Not sure how other people do it but 1 micro RDS serves many projects for me. Well worth the money for me.

Yea my hunch/hypothesis does not apply to slow languages like python. That's why I said a fast language that's compiled to native binaries. For example, D, Swift, or Go.

It's only a few lines of terraform to spin up a mysql or pg RDS instance. It can't get any easier, so why would I jump through extra hoops to use sqlite?

Its free to host compared to other RDMS which aren't cheap on most IaaS, and spinning up an instance is as easy as deploying it alongside your code.

terraform itself is a monster I want to avoid ..

I want no dependencies .. and no dependency manager.

Reply on news.ycombinator.com