Follow

Is there any really excellent reason to use PostgreSQL over MySQL/MariaDB for an app like or any other federated app? I know MySQL much better and could develop for it much faster, but if PostgreSQL is inherently better at storing and retrieving records concurrently or something like that, I'd be willing to stick with using it.

@Readlebee i don't have much experience but I know many people who won't using anything else after postgres. It works with JSON eg which is cool

@Readlebee I recognize that familiarity is important also and you're totally right to take that into account. On the other hand, this might be a good excuse to dive into a ⭐️ new thing ⭐️!

Either way, good luck and I'm excited to use Readlebee! 😀

@edwardloveall Thanks for that reference, it's really helpful! I do feel like Postgres is probably the "right" choice for this project. Plus knowing more than just MySQL will definitely be more enriching in the long run. 😁

Thanks! I hope I'm able to deliver something worth being excited for! 😅

@edwardloveall @Readlebee A longer explanation with tons of details could be:
grimoire.ca/mysql/choose-somet

It's true that familiarity is a plus, but is it really that different when you start a new project? I would imagine what will make most of the difference is the SQL, and that should be largely the same... except for the extra things you will be able to use in PG.

@Readlebee I know and love Postgres, but not MySQL. I do know there are some nice features Postgres has that MySQL doesn't — queryable JSON columns, materialized views... MySQL is less supportive of triggers, stored procedures, subqueries, ... To me MySQL feels like a Honda Civic. Reliable, but nothing fancy. Postgres is more lux. Still gets you to the same place, just a little more comfortably (and fun!)

@Readlebee

Use #SQLite. I don't care if it is not as performant/cool/sexy. It never needs to be installed, requires no maintenance. Laypeople (usually) cannot screw it up and file spurious bug reports about it. Not even book geeks.

@Amgine I love SQLite, but it's definitely the incorrect database choice for this project. I'm anticipating federation support, which will require handling a lot of data and accessing the database many times simultaneously.

SQLite is more geared toward single-user or light multi-user interaction rather than what will do, so having a separate database manager will be essential to ensure that no (or at least less) corruption or loss of data happens when multiple connections go at once.

@Readlebee

A stand-alone Readlebee for a book club or or a smalltown library would be a cool option just by itself. (Probably on an #RPi, using a USB stick for storage, wifi for network… bet I could hide it in the false ceiling of the 2nd floor bathroom.)

Guerilla websiting.

@Amgine Yeah, I really like that idea a lot! Allowing Readlebee *not* to federate would probably be a good option to include anyway, so that'll go on the list for sure. :)

@Readlebee
The advantage of Postgresql wrt to ActivityPub or any other json based protocol is that you can do ad hoc searches on protocol records stored in fields with the jsonb data type. You don't build your application on this; you still break out any properties you want to search on from the application so that there's an index to profile. When you want to refactor an application to add an index, however, it's a lifesaver

Sign in to participate in the conversation
FLOSS.social

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).