Sentry 9.1 and Upcoming Changes | Hacker News Reader

Sentry 9.1 and Upcoming Changes

blog.sentry.io

28 pointsbramen8 comments

As a rule, my dev environments are decoupled and have no non-local dependencies, 'cause I don't always work with an internet connection. So while I've liked Sentry at prior jobs and have consistently recommended it, I have not been using it personally on my own stuff. But recently, a number of projects I'm now working on require more elaboration on errors I've used I was just saying the other day "huh, I forgot about self-hosted Sentry, I can use that for development and I can pay them in production". But I guess I should track down another alternative that isn't going to add gigs and gigs of memory to a dev stack; I like Kafka and Zookeeper and all that as much as the next nerd but if my product doesn't need it I'm certainly not running it for an exception catcher.

The marketing spiel in this is pretty shitty, too. "You can evaluate whether you want us to handle this with the cloud!" I think I'd rather evaluate whether or not I want to use you.

As I said, my automatic recommendation has always been Sentry; I now need to reevaluate this. Any locally-hostable-for-dev,-SaaS-for-prod options I should be looking at?

This looks like a big enough change that someone could fork Sentry. Disconnecting the the fancy search and reenabling sqlite shouldn't be lots of work for the next few releases. I bet there are companies that will do it in private - would be interesting to see if any of them go public though.

It could be, and I might also just sit on the current version in a dev environment (as I assume they won't break their public API anytime soon). But the first time I hit jank I'm going to be going "man, why did I take the path of least resistance?".

It must be hard to maintain their open source product. I can imagine it’s difficult to have 2 different backends that scale from self hosted to the thousands and thousands per second of the cloud. Along with the searching, HA, etc

Absolutely is - sqlite had been valuable for a long time as it made testing/local dev fast, but MySQL has always been a burden. Its made it hard for us to build optimal solutions in many cases as we had to cater to multiple different approaches to a solution. With our newer stuff we're actually able to remove a lot of the infrastructure cost/complexity by using a better solution (Clickhouse). Obviously has its costs, but its a net win.

> sqlite had been valuable for a long time as it made testing/local dev fast

FWIW, in my current project, I've deviated from my usual pattern of using SQLite for testing and Postgres for production and went all-in with Postgres in order to use some Postgres features that SQLite does not have (enum types, row-level locking). I have a very small shell script [1] for starting an isolated Postgres instance during test suite runs, and that works fine for me. The speed difference is about 100-200 ms per test suite run for the `pg_ctl start` and `pg_ctl stop`.

[1] https://github.com/sapcc/castellum/blob/master/testing/with-...

Kind of off-topic, but with the direction GitHub is going with features and 'embrace, extend, (and to be determined with pkg repo) extinguish', I wouldn't be surprised if GH comes out with a Sentry competitor by 2021.

It could be reasonable for them to buy Rollbar instead of creating their own.

Reply on news.ycombinator.com