4 ms·

What's the benefit?

by TIPSIO 4y ago

What's the benefit?

gjulianm 4y ago
I assume that easier installation, reduced attack surface, possibly more lightweight (regarding server load).
zimpenfish 4y ago
You don't have to spin up a MySQL (or Postgres) instance which is a moving part which doesn't need looking after. Obvs. you'll still need SQLite backups but they're a lot easier, especially with e.g. litestream.
dongobread 4y ago
For me, the ease of migration is huge as well as the ability to run WP on extremely low-end VPS with limited RAM.
- dpkirchner 4y ago
  Bet you could even host it in a container-based on demand system ala Google Cloud Run (ideally behind a CDN).
Someone1234 4y ago
- Entirely file based (and can be reasoned about as such, including backups/restores/migrations). - Reduced attack surface (e.g. no DBMS running on a potentially unsecured port, fewer code-execution vectors). - Reduced maintenance (SQLite's library will be patched as part of WordPress). Will it scale worse? Sure, but a lot of Wordpress installations simply don't need it, in particular if you throw a Wordpress cache (e.g. Super Cache, W3, etc) in front of the thing. You could Wordpress cache and then server cache on top of that (e.g. Cloudflare, CloudFront, etc), and I bet the thing could handle millions+ of impressions.
- fabian2k 4y ago
  You still have to keep the database nature of the SQLite file in mind when doing backups, as far as I understand it is not safe to just copy the file while the DB is running unless you use snapshots or ensure that nothing is written to the DB during that time. SQLite is still easier to manage than a standalone database server, so it is interesting in any case. But I'm not sure it makes backups easier.
  - deleted 4y ago
    [deleted]
  - duskwuff 4y ago
    Copying the database file is fairly safe, especially for an application that's likely to be read-mostly like WordPress. It could fail if the database was large enough that copying it took a nontrivial amount of time, and the database was modified during the copy operation -- but even then, there's a fair chance it'd be recoverable. SQLite is pretty resilient. The "safe" way of doing the backup would be: sqlite3 wordpress.db ".backup wordpress-backup.db" which writes out a new copy of the database file. Restoring the database would be as simple as renaming the backup to the main file -- the backup is a "real" database file; there's no import operation required.
  - johnchristopher 4y ago
    Well, you don't have to fiddle with drop statements and tag.gz formats and things like that and restoring is just a matter of putting the file back instead of importing huge numbers SQL instructions. You don't depend on php/phpmyadmin or a sql command to get a backup or to run it (no cpu are harmed during the process). Just copy the file. I can see old gotchas disappear like that (can't wait for the new ones !).
  - stonemetal12 4y ago
    The traditional back up process is 3 steps, 1) lock the file 2) copy the file 3) unlock the file. A second option is to use the SQLite command line tool, it provides a backup command. If you need something more complicated, SQLite provides a backup API you can make use of.
- notRobot 4y ago
  > - Reduced maintenance (SQLite's library will be patched as part of WordPress). Are you sure about this? I think it's a lot more likely that it'll use PHP's sqlite3 extension. Edit: confirmed, it uses PHP's built-in PDO SQlite3 driver: https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/db.php https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/...

What's the benefit?

by TIPSIO 4y ago

What's the benefit?

gjulianm 4y ago

I assume that easier installation, reduced attack surface, possibly more lightweight (regarding server load).

zimpenfish 4y ago

You don't have to spin up a MySQL (or Postgres) instance which is a moving part which doesn't need looking after. Obvs. you'll still need SQLite backups but they're a lot easier, especially with e.g. litestream.

dongobread 4y ago

For me, the ease of migration is huge as well as the ability to run WP on extremely low-end VPS with limited RAM.

dpkirchner 4y ago
Bet you could even host it in a container-based on demand system ala Google Cloud Run (ideally behind a CDN).

Someone1234 4y ago

- Entirely file based (and can be reasoned about as such, including backups/restores/migrations). - Reduced attack surface (e.g. no DBMS running on a potentially unsecured port, fewer code-execution vectors). - Reduced maintenance (SQLite's library will be patched as part of WordPress). Will it scale worse? Sure, but a lot of Wordpress installations simply don't need it, in particular if you throw a Wordpress cache (e.g. Super Cache, W3, etc) in front of the thing. You could Wordpress cache and then server cache on top of that (e.g. Cloudflare, CloudFront, etc), and I bet the thing could handle millions+ of impressions.

fabian2k 4y ago
You still have to keep the database nature of the SQLite file in mind when doing backups, as far as I understand it is not safe to just copy the file while the DB is running unless you use snapshots or ensure that nothing is written to the DB during that time. SQLite is still easier to manage than a standalone database server, so it is interesting in any case. But I'm not sure it makes backups easier.
- deleted 4y ago
  [deleted]
- duskwuff 4y ago
  Copying the database file is fairly safe, especially for an application that's likely to be read-mostly like WordPress. It could fail if the database was large enough that copying it took a nontrivial amount of time, and the database was modified during the copy operation -- but even then, there's a fair chance it'd be recoverable. SQLite is pretty resilient. The "safe" way of doing the backup would be: sqlite3 wordpress.db ".backup wordpress-backup.db" which writes out a new copy of the database file. Restoring the database would be as simple as renaming the backup to the main file -- the backup is a "real" database file; there's no import operation required.
- johnchristopher 4y ago
  Well, you don't have to fiddle with drop statements and tag.gz formats and things like that and restoring is just a matter of putting the file back instead of importing huge numbers SQL instructions. You don't depend on php/phpmyadmin or a sql command to get a backup or to run it (no cpu are harmed during the process). Just copy the file. I can see old gotchas disappear like that (can't wait for the new ones !).
- stonemetal12 4y ago
  The traditional back up process is 3 steps, 1) lock the file 2) copy the file 3) unlock the file. A second option is to use the SQLite command line tool, it provides a backup command. If you need something more complicated, SQLite provides a backup API you can make use of.
notRobot 4y ago
> - Reduced maintenance (SQLite's library will be patched as part of WordPress). Are you sure about this? I think it's a lot more likely that it'll use PHP's sqlite3 extension. Edit: confirmed, it uses PHP's built-in PDO SQlite3 driver: https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/db.php https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/...