121–130 of 364 posts
SQLite is definitely not a toy DB when it comes to its features, none will deny that. However, when you start to deal with hundreds of millions of records in a table, you kinda consider it a toy.
I'd still rather use PostgreSQL for my data needs. psql is quite nice too as an interface, and "setup and forget" replication for everything in the cluster and remote access makes up for slightly harder deployment and upgrades. Knowing that I can do anything and the change hits 3 hard drives in a span of few seconds on various machnies is nice. Tolerance for arbitrary down time of master/slave clusters is also nice.…
I agree that PostgreSQL has some great tooling around it. For SQLite replication, you might want to checkout Litestream: https://litestream.io/
Earlier quoted context omitted.
Also if you really need HA there are nice projects like https://dqlite.io/
Looking at https://dqlite.io/docs/protocol it seems like it does not allow for embedded usage though. Doesn't this turn it into more of a traditional client-server RDBMS?
> Dqlite is a fast, embedded, persistent SQL database with Raft consensus that is perfect for fault-tolerant IoT and Edge devices.
Earlier quoted context omitted.
Also if you really need HA there are nice projects like https://dqlite.io/
Looking at https://dqlite.io/docs/protocol it seems like it does not allow for embedded usage though. Doesn't this turn it into more of a traditional client-server RDBMS?
Earlier quoted context omitted.
Looking at https://dqlite.io/docs/protocol it seems like it does not allow for embedded usage though. Doesn't this turn it into more of a traditional client-server RDBMS?
Looking at the archtecture page [0] on that same website the second heading is "Embedding". [0] https://dqlite.io/docs/architecture
I'd also like to add the possibility of using SQLite databases as an application file format: https://news.ycombinator.com/item?id=23508923 I had to work on a data import/export tool some time ago and SQLite has simplified the design a lot.
While this makes things easy, you should not do this for any application file format where you except your users to share files. This is because opening a SQLite database file makes the SQLite library execute any arbitrary code that may be stored in that file. [0] Therefore, SQLite is really only suitable for local-only file formats, such as configuration files, and not for files that users will e-mail to each other.…
E: oh whoops missed the dev post above mine
Earlier quoted context omitted.
Access DB is still included in Microsoft Office
And LibreOffice has Base, a sadly often neglected component.
As for Access, it's access is limited due to the much higher price point of Business/Professional versions of Office. In terms of office suites, that version is about two to three times more expensive than an equivalent office suite from the mid-1990's (adjusted to 2021 dollars). In other words, people will only have Access if they feel that the additional cost is justified.
That additional cost may be fine for business use, yet it also means that people have less exposure to databases to start with. With respect to exposure, there also appears to be an absence of general purpose databases for home users these days. (By that I mean in terms of cost and ease of use.)
> not bothering with optimization (≈200 requests per page) What amount of SQL queries per page render is considered sensible? When I run more than 20 queries per request in my Rails apps (smallish internal tools for different companies) I get uneasy. I usually deploy the app on the same machine where the DB (not SQLite) runs, but I imagine if that weren't the case the app-DB roundtrips could soon dominate the whole t…
and they do. We have a GraphQL API backed by multiple microservices at a place I work. You become increasingly paranoid at every call you need to make.
It's also where ORMs completely fall over. ORMs are designed for, generally, one record to one query mapping. Which is why they are always leaky abstractions which need heroic acts of clever hacking to overcome. You know, rather than doing the sensible thing and just writing a single query that fetches data from multiple tables.
SQLite sort of encourages many queries, though, due to their design. I recall their docs even mention this point. But I've seen a few people in various threads that get bitten by this when they switch to a client/server DB.
I think it's perfectly fine to design your app around the characteristics of your database. Otherwise, you're missing out on optimizations and features you could be using and what would even be the point in favoring one DB over another if it's all the same to your app? You should pick the DB that matches the characteristics of your app anyway.
With no sense of overstatement here, SQLite is one of my favorite creations in the entire world, so I have a bunch of links some of you might find interesting if you want to dig further: https://github.com/sql-js/sql.js - SQL.js lets you run SQLite within a Web page as it's just SQLite compiled to JS with Emscripten. https://litestream.io/blog/why-i-built-litestream/ - Litestream is a SQLite-powered streaming replica…
Wow! The sql.js bundle is only 8kb. This is a hidden gem for sure. Thanks for pointing it out! EDIT: It's actually 1.2MB. Thanks for pointing it out :)
With no sense of overstatement here, SQLite is one of my favorite creations in the entire world, so I have a bunch of links some of you might find interesting if you want to dig further: https://github.com/sql-js/sql.js - SQL.js lets you run SQLite within a Web page as it's just SQLite compiled to JS with Emscripten. https://litestream.io/blog/why-i-built-litestream/ - Litestream is a SQLite-powered streaming replica…
Wow! The sql.js bundle is only 8kb. This is a hidden gem for sure. Thanks for pointing it out! EDIT: It's actually 1.2MB. Thanks for pointing it out :)