@me thanks :) If I may, unless you plan to have a lot of users or must store files on NFS or CIFS, just use SQLite and you'll get all your files in one place :)
I would be a big performance hit to store files in the database since everything is served directly from the zip files that Readeck creates.
@me I actually tested this by implementing sqlar and, even though it's good, it doesn't beat opening a file and copying data from some position to a writer.
And the sqlite driver Readeck uses doesn't provide the functions to read directly from a blob (sadly) and you end up with your 30Mb image in RAM before you can send it :)
My point was: with sqlite, your whole dataset is one folder and that's it. Plus, having a collection of files gives you the benefit of deduplication.
@me That said, I get your point and I actually agree. Only, if I have to choose between performances and backup convenience (on the hottest path), it's an easy choice :)
PS: the import / export commands are mostly there when you need to move from pg to sqlite or the other way around (and for portability). You can still use pg_dump, it'll work the same
In 3 days Pocket is shutting down, so it's high time to worry about a replacement, if you haven't already. I know a lot of folks took this as a cause to try more sophisticated knowledge management apps (hey @obsidian@mas.to
).
Personally, I was looking to keep the experience of the simple reading stack. And boy, @readeck@mastodon.online is exactly what I was looking for, and better than I was hoping for:
Last but not least, it can import your data from Pocket, so migration is pretty smooth. It did take a few hours to chew through ~2500 articles I've apparently saved over the years, since it had to fetch the links and re-extract the content. This is actually one gripe I have with the Pocket export: it just gives you a CVS with links and light metadata, but it doesn't export the saved article content. If you have a 10 year old link in there somewhere, ~pray~ donate to web archive gods that it has been saved there. If you care.
One thing that I wish worked differently is that it splits its state between database (SQLite or Postgres) and disk. I kind of wish everything went into the database, so that can be backed up together with the rest of Postgres index, but beggars can't be choosers. I'll take it.