4 ms·

Check out rqlite (https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite) for that functionality - "rqlite is a lightweight, distributed relational d

by smulc 6y ago

Check out rqlite (https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite) for that functionality - "rqlite is a lightweight, distributed relational database, which uses SQLite as its storage engine. Forming a cluster is very straightforward, it gracefully handles leader elections, and tolerates failures of machines, including the leader. rqlite is available for Linux, macOS, and Microsoft Windows."

emodendroket 6y ago
To me this is obviating a lot of the advantage of SQLite over any other RDBMS.
- dmurray 6y ago
  I thought the same, but maybe it's useful if you start with SQLite and decide to scale up to a distributed RDBMS without having to rewrite too much?
  - msla 6y ago
    Two thoughts: SQLAlchemy, at least, lets you switch from SQLite to Postgres in a configuration file. Isn't there a useful SQL subset which allows you to switch from one database to another without rewriting? There seems to be such a subset for C, for example, which multiple compilers all interpret the same way, and SQL is a standardized language, too.
    - dmurray 6y ago
      Yes, both of those are alternative solutions. Using a wrapper like SQLAlchemy is probably an improvement for most medium and large projects, but it has costs of its own. Using portable ANSI SQL - above the Hello World level - is something basically nobody does unless they make a serious effort, lean on linting tools and forego some of the most useful features of their DBMS. sh is perhaps a closer comparison than C here: it's at least possible to write portable C accidentally. And neither of these help you if you started with a SQLite database - an excellent choice for most - and decide that you need to support a dozen or a hundred concurrent users.
    - emodendroket 6y ago
      > Isn't there a useful SQL subset which allows you to switch from one database to another without rewriting? Only if you're happy throwing away a lot of the features, which is taking away from what makes SQL an attractive solution in the first place. Plus, even some basic things aren't the same between different implementations (e.g., SELECT TOP 1 * FROM t vs SELECT * FROM t LIMIT 1), so you'd really have to be testing with different RDBMSes the whole way through to make sure you didn't accidentally break compatibility.
the_duke 6y ago
rqlite is a separate daemon written in Go, negating most of the reasons to choose Sqlite in the first place. It absolutely has good use cases, but those are rather niche. You'll mostly be better off with the traditional postgres etc.
- snicker7 6y ago
  For web applications, having a separate daemon for sqlite is best practice anyway. SQLite doesn't play nice with multiple concurrent connections (costly locking, the possibility of data corruption). You typically need to offload transactions to a queue in a daemon thread.

by smulc 6y ago

emodendroket 6y ago

To me this is obviating a lot of the advantage of SQLite over any other RDBMS.

dmurray 6y ago
I thought the same, but maybe it's useful if you start with SQLite and decide to scale up to a distributed RDBMS without having to rewrite too much?
- msla 6y ago
  Two thoughts: SQLAlchemy, at least, lets you switch from SQLite to Postgres in a configuration file. Isn't there a useful SQL subset which allows you to switch from one database to another without rewriting? There seems to be such a subset for C, for example, which multiple compilers all interpret the same way, and SQL is a standardized language, too.
  - dmurray 6y ago
    Yes, both of those are alternative solutions. Using a wrapper like SQLAlchemy is probably an improvement for most medium and large projects, but it has costs of its own. Using portable ANSI SQL - above the Hello World level - is something basically nobody does unless they make a serious effort, lean on linting tools and forego some of the most useful features of their DBMS. sh is perhaps a closer comparison than C here: it's at least possible to write portable C accidentally. And neither of these help you if you started with a SQLite database - an excellent choice for most - and decide that you need to support a dozen or a hundred concurrent users.
  - emodendroket 6y ago
    > Isn't there a useful SQL subset which allows you to switch from one database to another without rewriting? Only if you're happy throwing away a lot of the features, which is taking away from what makes SQL an attractive solution in the first place. Plus, even some basic things aren't the same between different implementations (e.g., SELECT TOP 1 * FROM t vs SELECT * FROM t LIMIT 1), so you'd really have to be testing with different RDBMSes the whole way through to make sure you didn't accidentally break compatibility.

the_duke 6y ago

rqlite is a separate daemon written in Go, negating most of the reasons to choose Sqlite in the first place. It absolutely has good use cases, but those are rather niche. You'll mostly be better off with the traditional postgres etc.

snicker7 6y ago
For web applications, having a separate daemon for sqlite is best practice anyway. SQLite doesn't play nice with multiple concurrent connections (costly locking, the possibility of data corruption). You typically need to offload transactions to a queue in a daemon thread.