Sentry 9.1 and Upcoming Changes(blog.sentry.io)
blog.sentry.io
Sentry 9.1 and Upcoming Changes
https://blog.sentry.io/2019/05/14/sentry-9-1-and-upcoming-changes
8 comments
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-...
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.
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?