3 ms·

Honest question from someone currently in the middle of implementing my first SQLite deployment for a local data store in a desktop application (and is rather n

Honest question from someone currently in the middle of implementing my first SQLite deployment for a local data store in a desktop application (and is rather new to software development.) Is SQLite not ergonomic? I’ve previously played with mongodb through work and it was super simple and intuitive. But SQLAlchemy is super verbose and not at all intuitive despite being intellectually easy to grasp. It feels to me like it has decades of cruft built into the syntax and while I can appreciate that it means options it has not at all been nice to work with. I understand the issues with mongodb, but I managed to get it working in 30 minutes. Meanwhile, I’m 3 days into trying to get SQLAlchemy working. It feels to me that perhaps there may be a hole in the market for “GPT” friendly databases. Because SQLAlchemy is so verbose it kills the context window of GPT lmao.

malwrar 3y ago
For local/single-instance apps? Heck yeah, sqlite is a great choice. Just wrap all your queries behind functions in a db.py file and never think about application state until you’re forced to. SQLAlchemy is tempting, but honestly sql is already easy enough that I’ve found I spend far less time just writing plain sql queries. Most important thing is to get your actual application idea functioning quickly. Sqlite is fast to work with and low maintenance (your db is one file), and later if you found you made a mistake (too slow, no support for advanced sql features you need, you want concurrent access across multiple boxes) you can write a program to migrate your data in a single afternoon. Wasting time on more complex solutions early on is a pitfall that has stolen years of project time from me, just avoid misusing dependencies too badly and get your thing working first.
simonw 3y ago
Sounds like your problem is with SQLAlchemy, not with SQLite. My https://sqlite-utils.datasette.io https://sqlite-utils.datasette.io library might be a better fit for you. It's a much thinner abstraction than SQLAlchemy. Or just use sqlite3 from the Python standard library directly.

malwrar 3y ago

For local/single-instance apps? Heck yeah, sqlite is a great choice. Just wrap all your queries behind functions in a db.py file and never think about application state until you’re forced to. SQLAlchemy is tempting, but honestly sql is already easy enough that I’ve found I spend far less time just writing plain sql queries. Most important thing is to get your actual application idea functioning quickly. Sqlite is fast to work with and low maintenance (your db is one file), and later if you found you made a mistake (too slow, no support for advanced sql features you need, you want concurrent access across multiple boxes) you can write a program to migrate your data in a single afternoon. Wasting time on more complex solutions early on is a pitfall that has stolen years of project time from me, just avoid misusing dependencies too badly and get your thing working first.

simonw 3y ago

Sounds like your problem is with SQLAlchemy, not with SQLite. My https://sqlite-utils.datasette.io https://sqlite-utils.datasette.io library might be a better fit for you. It's a much thinner abstraction than SQLAlchemy. Or just use sqlite3 from the Python standard library directly.