gregmfoster

Thanks for writing this up! I really enjoyed the comparison. My team is considering moving some of our data to elastisearch out of postgres, and this analysis helps confirm some of our thoughts.

To me, the critical points here are:

> PostgreSQL has a single master and multiple read replicas, Elasticsearch has horizontal scalability via sharding.

> if you have a large data set search and search relevancy is critical to your application (for example, in e-commerce), using a dedicated search engine like Elasticsearch is going to perform better

I love the mentality of "default to using Postgres for everything, and specialize when you need to." In this case, it looks like you'll need to evolve text search out of Postgres the moment your dataset gets into the millions, which roughly matches my experience.

I love the idea of more book-focused social networks! Curious what the motivation here is to make it federated, instead of focusing on high-velocity user-focused product development. My greatest gripes with existing book-social-media-networks aren't the federation, but rather the dated UX.

I'm curious how much people prefer TUIs over editor-plugin-GUIs these days. I'm getting more and more persuaded by the plugin model personally - perhaps partly by how easy it is to discover, install, update, uninstall, etc VSCode plugins

I imagine this would be brutally hard for guitar - so often, my fingers are "touching" the correct strings, but not pushing down hard enough to trigger the note. Piano might be more feasible because you can watch the motion of the keys themselves.

Question - what is your root goal? Are you convinced video processing is the best way to achieve this?

yeah, it's really interesting, I've seen this confusion before

Congrats on the launch! How are you thinking about building an open-source company vs a closed-source?

why

nah, not real, I was just being silly :)

I like adopting a merge queue as a forcing function to deal with flaky tests.

It's like a rebase queue, but with more ref-log, and less tree inversion. Pull queues counter-intuitively lean on force-push-with-lease sub-commands, whereas monorepo merge queues have remote build caches for... sorry I blacked out.

FWIW, graphite.dev's MQ supports GitHub Enterprise Server

If a merge queue is light and fast, all repos could benefit from having it enabled by default

Seeing 421 on our AWS amplify splash page as well

This comment seems off topic?