41–50 of 330 posts
This is where the "MongoDB is webscale" meme came from.
The truth is SQLite and a single webserver or Docker container will be fine for 95% of web applications.
People really underestimate the advantage of simplicity vs perceived power.
Use SQLite.
One of my previous employers was using SQLite as a large distributed database - they had their own custom sharding strategy, but essentially the idea was to shard A accounts * B tables * C num_of_days with a .db file for every shard. When I first came and saw it, it...did not sound right. But I didn't want to be the guy who comes in and says "you are doing it wrong" month 1. So I went along with it. Of course, eventu…
The sqlite docs page has a nice article [1] on when to use an embedded database such as sqlite and when to go with a client/server model (postgres, mysql or others) When not to use sqlite: - Is the data separated from the application by a network? - Many concurrent writers? - Data size > 280 TB For device-local storage with low writer concurrency and less than a terabyte of content, SQLite is almost always better. [1…
Isn't MySQL MyISAM faster and this way constitute a better choice for a scientific number crunching application? I mean near 4GB DB, very simple schema, heavy reading load, little/no inserts and no updates.
https://docs.google.com/presentation/d/1Q8lQgCaODlecHa2hS-Oe...
Yes for all my sites: Nomad List, Remote OK, Hoodmaps, Rebase etc. No real issues at all.
I use it together with Rails and the horizontal sharding feature. Each customer has it's own sqlite database running in WAL mode. Since the app is internally used, traffic/writes are pretty predictable. I also do backups periodically with ActiveJob using `.backup` on the sqlite3 client. It's simple and nice because I just have to worry about running the app, and nothing else.
One of my previous employers was using SQLite as a large distributed database - they had their own custom sharding strategy, but essentially the idea was to shard A accounts * B tables * C num_of_days with a .db file for every shard. When I first came and saw it, it...did not sound right. But I didn't want to be the guy who comes in and says "you are doing it wrong" month 1. So I went along with it. Of course, eventu…
I guess the take away here is that this underscores that sqlite isn't for the 'large number of writers' scenario.
p.s. > I didn't want to be the guy who comes in and says "you are doing it wrong" month 1 Very wise
Pros:
- A single API server, no separate database to worry about, configure, and update.
- Backups are as simple as backing up one file every so often. SQLite even has an API to do this from a live connection.
- Handles way more concurrent users than we’ve ever needed.
- Dev and test environments are trivial and fast.
- Plenty of tools for inspecting and analysing the data.
Cons:
- There are certainly use cases it won’t scale to, or at least not without a bunch of work, but in my experience those are less than 1% of projects. YMMV.
- The type system (even with the newish stricter option) has nothing on Postgres. I realise this is basically a non-goal but I’d seriously love to somehow combine the two and get PG’s typing in a fast, single file embedded DB library.
- Postgres JSON support is also better/nicer IMO.