3 ms·
I'll give you an example of what I'm doing with SQLite. I have an app that organizes my movie collection. I use IMDB public datasets as data source. Because ve
by zeroq 1y ago
I'll give you an example of what I'm doing with SQLite.
I have an app that organizes my movie collection. I use IMDB public datasets as data source. Because versioning is hard, data changes over time (remember who directed Matrix?) it's just easier to rebuild the database every time.
A naive import of datasets is ~131M inserts.
It takes 10 minutes (of which 100M takes exactly 6 minutes). Another 10 minutes to further clean up the data, set up indexes, optimize and vacuum.
It's fine for the use case, but still it would be nicer to be able to achieve that in half the time.
The app has no dependencies, database is a single file I can store on S3 and with a little bit of magic use it as a real database - meaning I can run a complex queries over http on that whole database and exchange 50kb.
The client is a standalone HTML file with some JS. No need of server for client, no need for hosting for server except of that S3 bucket.
Sure, it's definitely a niche application, but, at least for me, it makes perfect sense. Start your app with zero deps and add only what you really need. There's too much projects that start with google-esque architecture, with plenty of microservices, only to reach MVP with technical debt the size of US treasury.
- CyberDildonics 1y agoI don't understand what you are trying to say here, this doesn't seem to have anything to do with single writer limitations.
- crazygringo 1y agoThat's not concurrent writes. You would see zero speedup. Your use case makes perfect sense for SQLite. It's a great example of what it's for. It won't benefit. That's my point.