4 ms·

Looks interesting. Why does it need a Postgresql server? For just a handful of users, isn't sqlite the leaner, yet sufficient choice? How does it compare to G

• nielsole 4y ago
  if they don't have PSQL specific queries, it might be a trivial change: https://github.com/jointakahe/takahe/blob/main/takahe/settings/base.py#L60 https://github.com/jointakahe/takahe/blob/main/takahe/settin...
  • simonw 4y ago
    I tried swapping that for SQLite and successfully ran the test suite about a week ago, but I've not tried that again against the large number of more recent changes.
• rch 4y ago
  I wonder if Postlite would work. Actually that looks more like an interactive client.... https://news.ycombinator.com/item?id=30875837 https://news.ycombinator.com/item?id=30875837
• scrollaway 4y ago
  SQLite is magical and incredibly lean, but it is not leaner than Postgres if you need real database features. You end up reimplementing a lot of features in code that belong in the db.
  • simonw 4y ago
    What kind of features are you talking about here? This doesn't match my experience from the last few years. SQLite in WAL mode is extremely capable. The only thing I really miss from PostgreSQL is that PostgreSQL has more built-in functions for things like date handling - but SQLite custom functions are very easy to register when you need them.
    • scrollaway 4y ago
      Constraints and validation for example. Efficient json store. Etc
      • simonw 4y ago
        SQLite has check constraints - and recent versions can have STRICT tables: https://www.sqlite.org/stricttables.html https://www.sqlite.org/stricttables.html It also has excellent JSON features - JSON maybe stored as text rather than a binary format like JSONB in PostgreSQL, but the SQLite JSON functions crunch through it at multiple GBs per second so it doesn't seem to matter.
        • deleted 4y ago
          [deleted]
        • scrollaway 4y ago
          Didn't know about strict tables, very cool!
• andrewgodwin 4y ago
  Author here - it's just to reduce support surface area. I know I'll need PostgreSQL's full text indexing and GIN indexes for hashtags/search eventually, and I probably also want to use some of the upsert and other specialised queries, and it's easier to just target one DB I know is very capable. For reference, when I say "small to medium", in my head that means "up to about 1,000 people right now".
  • Tepix 4y ago
    SQLite has full text search and upsert. GIN indexes sound cool - perhaps you can get away not using them however and instead support 2 DB backends? If you want to accomodate "small" and not just medium, that would be great! ;-)
  • UncleEntity 4y ago
    I was poking into this a bit yesterday. Is there any advantage to using a traditional db as opposed to a graph db since json-ld is just a text representation of graph nodes? I was thinking the easiest path would be have the server deal with all the activityPub stuff and expose something like a graphQL interface for a bring your own client implementation. Of all the stuff they shoehorned graphQL into this seems like a valid fit, like they were made for each other. Anyhoo, just my random thoughts…
    • manfre 4y ago
      For better or worse, many servers are targeting Mastodon API compatibility to be able to leverage the existing clients. Adding GraphQL increases surface area without solving the bigger issue of creating the clients.
      • UncleEntity 4y ago
        I didn’t get as far as looking into the mastodon API for clients but that makes perfect sense, I just assumed it was an overlay on the more general API. Mostly I was thinking how one could implement something in the most efficient way and graph databases/graphQL were literally designed for this stuff.