Miniflux vs FreshRSS at Iba pang RSS Reader sa VPS

Aling self-hosted RSS reader ang angkop sa maliit na VPS

Ang Miniflux ang self-hosted RSS reader na dapat gamitin sa maliit na VPS. Isa itong Go binary na katabi ng PostgreSQL. Sinusuportahan nito ang Fever at Google Reader APIs, kaya makakakonekta ang mga third-party phone app, at ang pag-upgrade ay isang docker compose pull. Piliin ang FreshRSS kung kailangan mo ng extensions at isang container na may SQLite sa loob nito.

Limang reader ang sulit ilaanan ng disk space sa isang VPS: Miniflux, FreshRSS, CommaFeed, yarr, at Tiny Tiny RSS. Inihahambing ng page na ito ang aktuwal na pagkakaiba ng mga ito: ang memory na kailangan ng bawat stack, ang database na kinakailangan ng bawat isa, ang sync API na kailangan ng phone app mo, at ang mangyayari kapag araw na ng upgrade. Ang bawat figure dito ay alinman sa inilathala ng project o simpleng arithmetic, at sinasabi ng teksto kung alin dito ang ginamit. Wala sa mga ito ang benchmark ng hardware mo, kaya sukatin ang sarili mong box gamit ang docker stats.

Ang limang reader, tig-isang talata

Ang Miniflux ay isinulat sa Go at inilalabas bilang isang statically compiled binary. Malinaw ang dokumentasyon nito tungkol sa nag-iisang mandatory dependency: “gumagana lamang ito sa PostgreSQL.” Walang SQLite mode. Mayroon itong REST API, Fever compatible API, at Google Reader compatible API, pati OPML import at export. PostgreSQL ang humahawak sa full-text search, kaya hindi optional ang database.

Ang FreshRSS ay nasa PHP at tumatakbo bilang isang container na naglalaman ng web server at application. SQLite ang default na database at hindi nangangailangan ng hiwalay na service, habang supported ang PostgreSQL at MySQL para sa mas malalaking installation. Sinusuportahan nito ang Google Reader API at Fever API. Natalakay na ang installation nito sa aming walkthrough ng FreshRSS sa isang VPS, kaya ikinukumpara ito ng page na ito sa halip na ulitin ang installation.

Ang CommaFeed ay Java sa Quarkus, na may layout na ginagaya ang Google Reader. Pinipili ang database nito sa build time, hindi sa run time, kaya naglalabas ang project ng isang image para sa bawat database: athou/commafeed:latest-h2 para sa embedded H2 database, athou/commafeed:latest-postgresql para sa PostgreSQL, at iba pang variant para sa MySQL at MariaDB. Native compiled builds ang mga tag na ito, at ang suffix na -jvm ay tumutukoy sa mga variant na sa JVM tumatakbo. Naglalantad ito ng REST API at Fever compatible API, at mula sa version 7.3.0 (August 2026), mayroon na rin itong Google Reader compatible API.

Ang yarr (yet another rss reader) ay isang Go binary na may embedded SQLite, at hindi nito kailangan ng container. Nakikinig ang plain ./yarr sa 127.0.0.1:7070. Maikli ang mga flag nito: binubuksan ito ng -addr 0.0.0.0:7070 -auth alice:secret sa network kapag may password, at inilalagay ng -db /data/yarr.db ang database sa path na gusto mo. Mayroon itong Fever compatible API. Ang pinakabagong tagged release nito ay v2.9, mula September 2026, na na-check noong October 2026, kasunod ng v2.7 noong June at v2.8 noong July, kaya aktibo itong muling dine-develop.

Ang Tiny Tiny RSS ang pinakamatanda sa lima at pinakamabigat patakbuhin. Itinigil ang orihinal na project sa tt-rss.org noong 1 November 2025, at ipinagpapatuloy ang development sa isang community fork sa github.com/tt-rss/tt-rss, na siyang opisyal nang setup reference sa dokumentasyon. Apat na service ang setup na iyon: isang PostgreSQL container, isang PHP-FPM application container, isang hiwalay na updater container na kumukuha ng feeds, at isang nginx container sa harap. Malinaw na sinasabi ng dokumentasyon na “PostgreSQL ang ginagamit ng setup na ito.” May sarili itong JSON API, na ginagamit ng Android client nito at ng ilang third-party app. Hindi ito naglalaman ng Fever.

Gaano karaming memory ang kailangan ng bawat stack

Ang mga figure sa ibaba ay mga budget, hindi aktuwal na sukat: ito ang memory ceiling na dapat hindi lampasan ng bawat stack sa isang maliit na VPS. Ang numero para sa CommaFeed ay mula sa sarili nitong published example ng project, na naglilimita sa container sa 256 MB. Ang iba naman ay mga ceiling na may natitirang headroom para sa feed fetcher, na siyang karaniwang biglang kumokonsumo ng memory kapag nagsimula ang refresh cycle.

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

Pinakamababa ang yarr sa 128 MB dahil isa itong binary at isang SQLite file, na walang database server at walang language runtime sa ilalim nito. Kailangan ng Miniflux ng 320 MB para sa 2 containers, at ang karamihan nito ay napupunta sa PostgreSQL, hindi sa Miniflux. Ang Tiny Tiny RSS ang outlier sa 640 MB para sa 4 containers, dahil magkahiwalay na process ang application, updater, database, at web server, at bawat isa ay may sariling heap.

Itakda ang mga ito bilang aktuwal na limits, hindi bilang mga inaasahan lamang. Saklaw ng Memory limits sa Docker Compose ang syntax at ipinapaliwanag nito kung ano ang ginagawa ng container kapag naabot nito ang ceiling. Kapag walang limit ang isang container, hindi ito maayos na magfa-fail kapag napuno ang server: pipili ang kernel ng process na papatayin, at kadalasan ay hindi ang container na nagdulot ng pressure ang napipiling biktima.

Aling database ang ipipilit sa iyo ng bawat reader

Ang database ang pinakamalaking pagkakaiba sa pagpapatakbo ng limang ito. Mas malaking desisyon ito kaysa sa anumang pagkakaiba sa user interface, dahil tinutukoy nito ang backup procedure mo at ang risk sa upgrade.

Kailangan ng Miniflux at ng official Tiny Tiny RSS setup ang PostgreSQL. Nagbibigay ito ng tunay na full-text search at ligtas na concurrent writes. Kapalit nito ang isang karagdagang container, isang volume, at isang paulit-ulit na problema: hindi kayang i-migrate ng official PostgreSQL images ang data sa pagitan ng major versions habang nasa lugar pa rin ito. Tahasang sinasabi ito sa dokumentasyon ng Tiny Tiny RSS, at nagbababala na “walang suporta ang official PostgreSQL containers para sa pag-migrate ng data sa pagitan ng major versions.” Para sa isang feed reader, ang praktikal mong mga opsyon ay i-pin ang lumang major version, o mag-dump at mag-restore gamit ang pg_dump at pg_restore. Idinodokumento rin ng PostgreSQL ang pg_upgrade at ang replication-based upgrades. Sulit ang dagdag na setup ng mga ito sa malalaking database kung mahalaga ang kaunting downtime, ngunit bihira namang ganoon kalaki ang database ng isang feed reader. Magplano para rito isang beses bawat isa o dalawang taon.

Ang SQLite ang default ng FreshRSS at ng yarr. Isang file lang ito; walang server, port, o password. Maayos itong gumagana para sa isang tao na may ilang daang feed, at bumabagal kapag sabay-sabay na nagsusulat ang maraming user. Sa ganitong sitwasyon nagsisimulang maging kapaki-pakinabang ang PostgreSQL option ng FreshRSS. Nagdagdag ang yarr ng optional PostgreSQL support sa v2.7, ngunit ang embedded file ang karaniwang paraan ng pagpapatakbo nito.

Ang H2 ang embedded default ng CommaFeed. Pag-isipan muna ito bago magsimula, dahil pinipili ng CommaFeed ang database nito kapag bina-build ang image. Ang paglipat mula H2 patungong PostgreSQL ay hindi simpleng configuration change. Ibang image ito, kasama ang data migration na ikaw mismo ang kailangang magsagawa. Kaya magdesisyon bago magkaroon ng isang taong read history sa system.

Gagana ba ang phone app mo

Mas marami ang naaapektuhan ng tanong na ito kaysa sa inaakala ng karamihan, dahil kalahati lamang ng paggamit sa feed reader ang web interface.

May Fever compatible API at Google Reader compatible API ang Miniflux, kaya nakakakonekta rito ang karamihan ng iOS at Android client. Pareho ring sinusuportahan ng FreshRSS ang dalawang API, at tinutukoy ng sarili nitong documentation ang pagkakaiba ng mga ito: ang Google Reader API ang “best” dahil kumpleto ang feature support, samantalang may “limited features and less efficient” na behavior ang Fever API. Kailangan ding gumawa ng dalawang hakbang sa FreshRSS bago makapag-log in ang anumang app. I-enable ang “Allow API access (required for mobile apps)” sa ilalim ng Authentication, pagkatapos ay gumawa ng API password sa user profile. Kapag nilaktawan ang API password, authentication failure ang lalabas sa app kahit patuloy na gumagana ang web login. Nakalilito ito kung hindi mo alam kung saan titingin.

May suporta na rin ang CommaFeed sa parehong API: matagal na nitong mayroon ang Fever compatible API, at nagdagdag ang version 7.3.0 ng Google Reader compatible API para sa mga app na hindi sumusuporta sa Fever. Gumamit ng 7.3.0 o mas bago kung Google Reader lamang ang sinusuportahan ng app mo. Naglalantad ang yarr ng Fever compatible API at wala nang iba, kaya gumagana ito sa mga client na kayang gumamit ng Fever ngunit hindi sa mga app na Google Reader lamang ang sinusuportahan. Sarili nitong API ang ginagamit ng Tiny Tiny RSS, kaya kailangan mo ng client na partikular na ginawa para rito. Tiyaking sinusuportahan ng napili mong app ang reader bago ka mag-import ng 300 feed dito.

Isang gumaganang compose file para sa isang 1 GB na box

Ito ang Miniflux stack, na inangkop mula sa sariling Docker example ng proyekto noong October 2026. Naka-bind sa loopback ang published port, tahasang itinakda ang listen address, at parehong may memory limit ang dalawang container.

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

Tatlong linya sa file na iyon ang madalas maling naise-set. Inuulit ng LISTEN_ADDR=0.0.0.0:8080 ang itinakda na ng official image sa Dockerfile nito, kaya kasama ng miniflux/miniflux, isa lamang itong ligtas na safeguard at hindi fix. Mahalaga ito kapag sarili mong image ang bina-build mo o packaged binary ang pinapatakbo, dahil ang documented default ng binary ay 127.0.0.1:8080. Hindi maaabot sa published port ang prosesong naka-bind sa loopback sa loob ng container, kaya magkakaroon ka ng connection reset kahit mukhang healthy ang container. Ang volume path na /var/lib/postgresql ay para sa PostgreSQL 18; sa version 17 at mas luma, sa /var/lib/postgresql/data ini-store ang data. Kapag maling path ang mina-mount, wala sa volume ang data directory, kaya mawawala ang lahat sa susunod na pag-recreate ng container. Pinananatili ng 127.0.0.1:8080:8080 na hindi nakalantad sa public internet ang port, dahil kapag nag-publish ng port nang walang address, naglalagay ito ng rule sa chain na hindi minamanage ng ufw. Ipinaliliwanag ng Ang mga Docker port ay lumalampas sa ufw ang mekanismong iyon, at ang isang Traefik reverse proxy ang ginagamit para ilagay ang TLS sa harap nito.

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

Dapat ilista ng docker compose ps ang parehong serbisyo bilang running, at dapat markahan ang database bilang healthy. Sa unang pag-start ng Miniflux, nilo-log nito ang schema migrations; ito ang tina-trigger ng RUN_MIGRATIONS=1. Ipinapakita ng docker stats --no-stream ang live memory column, at iyon ang numerong ihahambing sa mga ceiling sa chart sa itaas. Kung paulit-ulit na nagre-restart ang Miniflux container, basahin ang log nito: nangangahulugan ang connect: connection refused na nag-start ito bago handa ang PostgreSQL na tumanggap ng mga connection. Ito mismo ang pinipigilan ng condition na service_healthy, kaya tiyaking nanatili ang condition pagkatapos ng mga edit mo. Kung bago sa iyo ang Compose, inuuna ng Mga pangunahing kaalaman sa Docker Compose sa isang VPS ang pagpapaliwanag sa layout ng file.

Ano ang hindi kasya sa isang 1 GB na box

Ang Tiny Tiny RSS ang dapat laktawan. Gumagana ang opisyal nitong four-service stack sa isang 1 GB VPS kung wala nang ibang ginagawa ang VPS na iyon. Hindi ito gagana roon kasabay ng isa pang database-backed application at reverse proxy. Ang four services ay nangangahulugan ng four sets ng overhead, at PostgreSQL ang isa sa mga ito.

Kasya ang CommaFeed, pero sa H2 image lamang at sa 256 MB cap na itinakda sa sarili nitong example ng proyekto. Ang kombinasyong sumisira sa maliit na box ay ang CommaFeed na kasabay ng hiwalay na database server. Mas lumalala ito sa -jvm image variants, dahil nagbababala ang documentation ng proyekto na greedy ang JVM bilang default at hindi nito ibinabalik sa operating system ang memory na hindi ginagamit. Ang latest-h2 at latest-postgresql tags ay native builds, na inirerekomenda ng proyekto dahil mas mababa ang memory use ng mga ito. Kaya manatili sa mga iyon maliban kung may dahilan kang patakbuhin ang JVM.

Kapag naubusan ng memory ang isang box, pumipili ang kernel out of memory killer ng isang process at tinatapos ito. Nagpapakita ang dmesg -T ng linyang gaya ng Out of memory: Killed process 1234 (java). Pagkatapos, basta na lamang nawawala ang container mula sa docker compose ps nang walang mensahe sa application log, dahil hindi na nakapagsulat ng mensahe ang application.

Paano gumagana ang mga upgrade sa bawat isa

• Miniflux: docker compose pull && docker compose up -d, at inilalapat ang mga schema migration sa pagsisimula habang nakatakda ang RUN_MIGRATIONS=1. Hindi Miniflux ang panganib sa upgrade. Ang PostgreSQL major version na nasa ilalim nito ang panganib.
• FreshRSS: i-pull ang bagong image. Kapag SQLite ang gamit, walang database engine na kailangang i-upgrade, kaya karaniwang nagmumula ang mga problema sa mga third-party extension na hindi nakasabay sa mga pagbabago.
• CommaFeed: i-pull ang image variant na tumutugma sa iyong database. Kapag lumipat mula latest-h2 patungo sa latest-postgresql, hindi awtomatikong naililipat ang iyong data.
• yarr: palitan ang binary at panatilihin ang database file. May mga release noong June, July, at September 2026. Ang v2.9 ang pinakabago noong October 2026, kaya pana-panahong tingnan ang release page.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Awtomatikong nag-a-update ang application container sa pagsisimula. Iniuugnay ng FAQ ng proyekto ang mga error sa schema update sa sirang volume o override setup, kaya suriin muna ang mga iyon kapag lumitaw ang error. Kung kumukuha pa rin ng images ang iyong compose file mula sa retiradong tt-rss.org project, palitan ito ng images ng fork (supahgreg/tt-rss sa Docker Hub o ghcr.io/tt-rss/tt-rss).

Gumawa ng database dump bago ang alinman sa mga ito, hindi pagkatapos.

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

Magkano ang bandwidth na nagagastos sa refresh interval

Ang mga numero sa ibaba ay batay sa arithmetic, hindi sa aktuwal na measurement. Ipinapalagay ng mga ito ang 100 feed, isang request bawat feed sa bawat interval, at 40 KB bawat response. Karaniwang mas mababa ang totoong traffic kapag hinahawakan ng server ang conditional requests, at mas mataas kapag buong article text ang dala ng mga feed.

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

Ang limang minutong interval para sa 100 feed ay 864,000 request at humigit-kumulang 34.6 GB bawat buwan. Ang hourly polling ay 72,000 request at humigit-kumulang 2.9 GB. Kasama sa Miniflux ang POLLING_FREQUENCY na nakatakda sa 60 minuto. Ito ang huling row ng chart na iyon, at tama ang default na ito para sa halos lahat. Hindi mas mabilis dumarating ang article dahil mas madalas mo itong hinihingi.

Ang conditional requests ang dahilan kung bakit mas mababa sa arithmetic ang aktuwal na bilang. Ang reader na nagse-save ng ETag at Last-Modified headers na ibinalik ng feed ay ibinabalik ang mga ito bilang If-None-Match at If-Modified-Since. Kapag walang bagong content ang server, sumasagot ito ng 304 Not Modified nang walang body. May gastos pa rin ang connection para sa handshake, pero wala nang payload. Ang mga feed na hindi tumatanggap ng conditional requests ay ipinapadala ang buong document sa bawat request. Dahil dito, maaaring ilang malalaking feed lang ang bumuo sa malaking bahagi ng iyong transfer bill.

Maaari ka ring ma-block kapag sobra ang polling. Ang server na nagpasiyang masyado kang maraming request ay sumasagot ng 429 Too Many Requests, at may ilang site na 403 naman ang isinasagot. Itinatala ng Miniflux ang huling error laban sa mismong feed. Kaya ang feed list ang unang dapat suriin kapag tumigil sa pag-update ang isang feed habang patuloy na gumagana ang iba.

Nawawala ang mga feed, at hindi backup ang OPML file

Mas mabilis masira ang mga feed kaysa sa inaasahan mo. Nag-e-expire ang mga domain, lumilipat ang mga site sa platform na walang feed, at ang URL na dating naghahatid ng XML ay nagsisimulang maghatid ng HTML error page na may 200 OK status. Iyon ang mahirap na kaso: nagtatagumpay ang fetch, nabibigo ang parse, at nagtatala ang reader ng parsing error sa halip na network error. Minsan bawat taon, ayusin ang feed list ayon sa huling update at tanggalin ang mga matagal nang walang bagong content.

Ang OPML export ay listahan ng iyong mga subscription. Ang standard na OPML file ay naglalaman ng mga feed URL at pangalan ng folder. Nagdaragdag ang FreshRSS ng sarili nitong XML namespace na naglalaman din ng mga setting para sa bawat feed, gaya ng refresh interval, XPath scraping selector, at auto-read filter. Ngunit walang OPML export na naglalaman ng read state, starred article, o text ng artikulong sinave mo. Kapag in-import mo ang OPML sa bagong install, maibabalik ang mga feed mo, ngunit mamarkahang unread muli ang bawat artikulong nabasa mo na.

Ang mahalagang i-back up ay ang database. Para sa PostgreSQL, ang pg_dump command sa itaas ang buong proseso. Para sa SQLite reader gaya ng FreshRSS o yarr, ihinto ang writer at kopyahin ang file, o kumuha ng consistent copy habang tumatakbo ito gamit ang sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". Ang simpleng cp ng database na kasalukuyang sinusulatan ay maaaring lumikha ng file na hindi na mabubuksan sa ibang pagkakataon, dahil maaaring makuha ng copy ang write na hindi pa tapos. Pagkatapos, regular na ipadala ang mga file na iyon sa labas ng server. Ito ang gamit ng restic backups sa isang VPS. I-restore ang isa sa mga ito sa isang scratch container kahit isang beses upang matiyak mong gumagana ang procedure.

Isa ang feed reader sa pinakamurang serbisyong maaari mong patakbuhin nang sarili, kaya kasama ito sa bawat listahan ng mga serbisyong sulit i-self-host sa 2026. Magpatakbo ng sarili mong SearXNG instance sa tabi nito upang manatili sa hardware na kontrolado mo ang pagbabasa at paghahanap.

FAQ

Aling self-hosted RSS reader ang gumagamit ng pinakamaliit na memory?

yarr. Isa itong binary na ginawa sa Go na may naka-compile na SQLite, kaya walang hiwalay na database server o language runtime, at sapat na ang 128 MB na ceiling. Kapalit nito ang limitadong features: Fever API lamang ang sinusuportahan nito, at ang pinakabagong release nito ay v2.9 mula Setyembre 2026. Kung kailangan mo ng suporta sa Google Reader API at full text search na may halos kaparehong memory footprint, mas angkop ang Miniflux kasama ang PostgreSQL sa 320 MB.

Maaari ba akong magpatakbo ng self-hosted RSS reader sa 1 GB VPS?

Oo. Kasya ang Miniflux na may PostgreSQL sa humigit-kumulang 320 MB kapag itinakda mo ang mem_limit sa parehong container, at kasya naman ang FreshRSS na may SQLite sa isang container. Ang dapat iwasan sa 1 GB ay ang official Tiny Tiny RSS stack, na may 4 service kabilang ang sarili nitong PostgreSQL. Palaging magtakda ng memory limits, dahil kapag walang limit ang isang container sa punô nang server, maaaring patayin ng kernel ang isang process. Madalas database ang napipiling patayin, sa halip na ang application na sanhi ng problema.

Alin sa mga ito ang gumagana sa iOS at Android RSS app?

Sinusuportahan ng Miniflux, FreshRSS, at CommaFeed 7.3.0 o mas bago ang parehong Fever compatible API at Google Reader compatible API, kaya halos anumang mobile client ay makakakonekta. Fever API lamang ang iniaalok ng yarr. Sarili nitong API ang ginagamit ng Tiny Tiny RSS, kaya kailangan mo ng client na ginawa para rito. Sa FreshRSS, kailangan mo ring i-enable ang API access sa ilalim ng Authentication at magtakda ng hiwalay na API password sa profile. Kung hindi, mabibigo ang app na mag-log in kahit gumagana pa ang website.

Backup ba ng RSS reader ko ang OPML export?

Hindi. Binubuo muli ng OPML ang subscription list mo. Kasama rin sa extended export ng FreshRSS ang mga setting at filter ng bawat feed, pero nasa database ang read state, starred items, at article text. I-back up mismo ang database gamit ang pg_dump para sa PostgreSQL, o isang .backup command para sa SQLite, at kopyahin ang resulta palabas ng server.

Sinusuportahan ba ng Miniflux ang SQLite?

Hindi. Ayon sa documentation ng project, “works only with PostgreSQL” ito. Ginagamit ng full text search ang mga feature ng PostgreSQL, kaya walang mas magaan na mode na maaaring paglipatan. Kung gusto mo ng feed reader na walang database container, patakbuhin ang FreshRSS gamit ang default nitong SQLite backend, o ang yarr gamit ang embedded file nito.