Hacker News Reader

Comment by kick | Hacker News Reader

Pleroma is significantly more lightweight than Mastodon, is compatible with both Twitter and Mastodon clients, and is one of the bigger (maybe the biggest that isn't working on Elixir itself?) free software Elixir projects. Worth giving a look if any of that interests you!

View on HN

It still requires the user to install and admin a postgres instance which already makes it a non-starter for 99% of the target audience, this design choice is tragically stupid - the chance that an instance of pleroma will reach a usage volume that can't be handled by sqlite and basic caching is not on the horizon, if they ever reach this problem they could then develop a version that works against an actual rdbms.

It's pretty much fire-and-forget. I know a bunch of non-technical people who are running Pleroma instances: you don't have to worry about it that much.

Pleroma is built using Elixir + Phoenix (iirc), which has excellent Postgres support with Ecto. That could have been a design decision. Postgres also supports some features SQLite doesn't, such as array types. For certain applications (such as tagged imageboards, boorus), that makes anything but Postgres nearly a non-starter. SQLite data type storage can also be a concern.

Chances are, if you have a server capable of running the Elixir + web framework stack, storage space for cached images, and a proxying web server, Postgres probably isn't much of an overhead on top of that.

Bare in mind that each fedi instance dosen't only host the content generated by users, but also whatever content they repeat/reply to. The fact it needs to be stored (or cached) is one reason why there's so much blocklisting/defederation - because people may not want to host certain content from instances known to commonly host it. It may even store more from the public timeline (I'm not sure about the specifics of Pleroma). Nevertheless, even with five users, you can fill up quite a lot of space in a database and on the filesystem.

Your strong statement about postgres doesn't sound right to me. You can't use an array values as foreign keys. Array column wouldn't be my first choice even it could do this: you're limited and constricted in usage overall for a little gain if any. Which imageboard/booru engines use array column for tags?

Danbooru (and forks like Moebooru) and Philomena use string arrays in the database for tags.

Edit: nevermind, Philomena has a table for the many-to-many relationship and uses Elasticsearch for the heavy lifting.

Why arrays are preferable over m2m tables? What so special about pg arrays that makes anything but them inferior in "tagging" case? I genuinely don't get it.

Accodring to these rough benchmarks, it's faster to use arrays rather than joins:

https://shon.github.io/2015/12/21/postgres_array_performance...

https://gist.github.com/joevandyk/031cf5812bd656887623

To search for a post with multiple tags, you need to do a join for each tag. You don't have that problem with arrays.

Thanks, that looks cool.

We do provide a step-by-step guide, which also involves installing postgres. In general, I think installing Elixir and Erlang is the much scarier part for most people, because few people have ever used them.

Sadly, we can't just use SQLite because we use Postgres-only features like jsonb extensively.

Not suggesting that sqlite could be dropped-in as replacement but https://sqlite.org/json1.html

You’re not entirely incorrect, but you’re not being kind, either.

Really all we’re talking about here is whether or not the thing that writes the files is in-process or an adjacent process.

If they can manage to run Pleroma, they can manage to run a Postgres beside it. I think the hurdle you are describing is to self-hosting anything in general. Standing up a self-hosted postgres is actually easier/simpler/better supported than some random weird elixir app.

Sorry, but it's true for the other steps as well with postgres being a particularly pain because it is a networked service that requires administration, security minding etc. The end result is a high-friction onboarding process and the fact that it is technically justifiable is besides the point for people who just want to use the thing not to hack on it.

The "if they can manage to run Pleroma" is not a very helpful approach to actually get more people to run Pleroma.

Haven't looked into the Plemora code myself, but it'd likely be feasible to patch it to be sqlite compatible. Unless there's a lot of Postgres specific SQL (triggers? mat views? hyperlog data types?) and the older version of Ecto the SQLite adapter uses. Still it would be fun to something like Plemora run on a RPi4 without needing Postgres. Then again, maybe Postgres would run alright... :-)

It's no feasible, we use a lot of postgres specific features. Pleroma with postgres runs fine even on Raspi 2.

Thanks for the info! Well maybe someday I'll see if I can bake a Nerves image with Postgres running on it. If I'm going to install it might as well on an RPI right?

I think standing up pretty much ANY type of server might be a non-starter for 99% of the audience...But then proper documentation would resolve that. In the case of pleroma, the database stuff is simpler, while the elixir and erlang stuff is what is dark magic...though that could be because my background is mostly LAMP sort of stuff. Thankfully, there is documentation for setting up/administering a pleroma instance, and as with most things, better versions of the documentation will surface more and more as time goes by.

It's sort of a "doomed if you do, doomed if you don't issue". SQLite lowers the barrier to start, but if your community grows even modestly then you'll be facing a very scary database migration (or at least scary for small admin teams).

I suspect a soft fork or subversion targeted towards small instances might be more sustainable, but that obviously requires more developers to build and maintain that.

Reply on news.ycombinator.com