That would also make backing everything up way easier.

Hi @fguillot - are you open for a pull request adding sqlite support?

@gergan I took a very quick peek at the code the other day. Seems you'd need to borrow two methods from the pq package, which are used in Miniflux:

• Array
• QuoteIdentifier

Couldn't find any other code specificly tied to Postgres at first glance. So it looks like changing database drivers could be feasible without too much of a hassle.

Hi @fguillot - are you open for a pull request adding sqlite support?

I'm not against that. However, I'm a little bit concerned about the number of changes required.

Not sure either about the maturity of pure Go Sqlite drivers compared to https://github.com/mattn/go-sqlite3

I've had a quick look at the table definitions (DDL) and there will be some problems - for example the hstore extension, there is no "with timezone" datetime type in sqlite. Probably there will be tons of other problems too. I will not have the time in January to do any work on this.
Probably the best way would be to just try to make the code work with sqlite and if the changes to the code are not minimal, than probably it is not a good idea.

It is weird that Miniflux uses timestamp with timezone at all, as this type is in general discouraged if you are using any form of ORM or anything. It has only a little bit sense when there is human operator on the DB, but other than that it introduces more problems than it solves. And hstore technically can be replaced by JSON fields.

sqlite, please. postgresql is the biggest weakness of miniflux.

Id love sqlite too.

Just poking in here: I know that GoToSocial also had to look for a pure-Go binding to SQLite, and this is the one they use: https://gitlab.com/cznic/sqlite

Probably worth checking out.

There are multiple implementations of Go SQLite without CGo - SQLite Benchmarks. The one that you mean (@clarfonthey) is probably the modernc.org one in the benchmark. I have looked over the database once more yesterday, and the hstore field was converted to separate fields in the meantime. But there are many timestamp with time zone fields there, and I'm not sure why they need to be in local time zones. As @hauleth already said, this probably has some historical reasons - the first step would probably be to try and convert the complete database to UTC. And after that, look at what still needs to be done for SQLite.

hope this gains some traction, id love to go back to a lightweight version of google reader

i found some additional info about timestamp with time zone (timestamptz) in this article https://community.spiceworks.com/topic/2454825-zone-of-misunderstanding

what i understand is that the postgres driver performs the time conversion from db stored time with timezone to the local time of the user hitting the db, and this is something that postgres guarantees (or is it a guarantee that the client lib is enforcing? 🤷‍♂️)

using sqlite, this would have to be done in client code

in any case, timezones are hard 😀

p.s.: the postgres article where i found the link to the timestamp with time zone reference https://challahscript.com/what_i_wish_someone_told_me_about_postgres?ref=labnotes.org#follow-all-the-advice-from-the-folks-that-make-postgres

p.s.: i tested freshrss as it uses sqlite by default, but it just didn't work, nowhere near as clean and no-nonsense as miniflux

As much as I admire @jvoisin's work on this, I think the Miniflux FAQ provides excellent arguments against SQLite. I would find it somewhat regrettable if this clear stance were to be abandoned.

@dertuxmalwieder keep in mind the first point in the link you shared.

Focus on Simplicity

Sqlite makes miniflux simpler for users to deploy and maintain since they don't need to add more complexity with an external database. From a code standpoint sure supporting multiple DBs can add complexity for the developers but that's their decision to make if they find value in it.

provides excellent arguments against SQLite

Other than what I wrote above, the link you shared only mentions CGO as a major blocker for adding sqlite support which now can be avoided.

postgresql is an outstanding db, it powers fortune 500 companies, however, as others mentioned, it does add complexitiy in the miniflux use case, there may be tradeoffs in features, but im not really sure they're essential/critical 🤷‍♂️

… I think the Miniflux FAQ provides excellent arguments against SQLite. I would find it somewhat regrettable if this clear stance were to be abandoned.

If anything, @jvoisin’s efforts would make things simpler for most of us.
I have been using Miniflux for close to three years now and the only knock I have against it, is its use of Postgres.

I for one am going to be amongst the first to switch to Sqlite once it's supported

most of us.

[Citation needed]. PostgreSQL is not an obscure niche application on web-facing servers. SQLite is.

SQLite isn't that obscure in case of self-hosting applications. A lot of them support SQLite as it greatly simplifies self-hosting (wrt. backups, management, securing stuff, etc.).

most of us.

[Citation needed]. PostgreSQL is not an obscure niche application on web-facing servers. SQLite is.

Neither are obscure and SQLite’s popularity for the kind of audience Miniflux has, is not in doubt.