looking at the docs and examples, I see Workflows and Steps and Retries, but I don't see any Durable yet. none of the examples really make it clear how or where anything gets stored
I would recommend reading more of the pricing page. You'll learn that:
- $312/year and $960/year are for unlimited users, not per seat
- Additional error/event volume is priced separately from the base plan
- You can pay for error volume, either prepaid or on-demand, without a custom enterprise deal:
> Each of our plans comes with a defined quota, with the option to process additional events by setting a pay-as-you-go budget. You can also plan ahead and save 20% over the pay-as-you-go rates by reserving events.
Sentry's been around for ~15 years, and has been using a license fitting the Fair Source definition for ~5 years. This is not a "hastily preparing ourselves to be acquired" sort of move. What makes you think this is a sign of some impending change?
Sentry's pricing plan has never gone from 10k errors straight to "negotiated enterprise deal"; you must have missed something. I say this having been a Sentry customer for the past 7 years across multiple companies, always with a paid plan beyond 10k errors and never with an enterprise deal.
"they have seemingly just ignored the better option...obviously much nicer"
This comes off a bit presumptuous. I would assume that they are aware this is a possibility.
"having to use a web service to view you stack trace"
This is just not a downside that matters for this usage scenario. It's almost the same story as minifying your frontend JS bundle, uploading source maps to Sentry, then using Sentry to view an unminified stack trace from a user's browser. The user was never going to view that stack trace anyway, and I am not bothered by having to use Sentry to view it - I never would have seen it at all otherwise.
APoSD is a relatively quick high-signal read, and not really a source of additional chaos. You can get through it in a weekend or less.
It mostly gives you vocabulary and labels and explanations for things that you may already intuitively understand, and teaches you to notice small things that matter. It will probably make it easier for you to discuss and dissect some of the chaos you're already dealing with.
Love Kysely, been rooting for it ever since it was first released. Paired with kysely-codegen, it's my favorite TS <> SQL interface. Does just enough, but not too much.
Had lots of good experiences working with Knex.js over the years, and Kysely is the TS-native spiritual successor to Knex.
Yea, DuckDB is a slam dunk when you have a relatively static dataset - object storage is your durable primary SSOT, and ephemeral VMs running duckdb pointed at the object storage parquet files are your scalable stateless replicas - but the story gets trickier in the face of frequent ongoing writes / inserts. ClickHouse handles that scenario well, but I suspect the MotherDuck folks have answers for that in mind :)
I see a kysely + kysely-codegen (generates types from DB schema) setup as comparable to Prisma in TS integration, with the added flexibility/closeness-to-SQL of the querybuilder.
If you:
- have used/liked Knex (or similar querybuilders) before
- like the TS integration + type safety of Prisma
- but find Prisma to be a bit too magic/heavy with its query engine and schema management
You sound like you're trying to have it both ways: "OTel solves a problem that is irrelevant unless you're massive" but also "well of COURSE it can work if you're not massive, how massive are you?"
There are tons of startups and other not-fortune-x00 orgs benefitting from what OTel provides. Your claim that OTel is irrelevant outside fortune-x00 cos is very clearly not true.
most or all of the observability domain experts i'm familiar with either stopped talking about "pillars" several years ago, or have been actively speaking against the "3 pillars" framing for several years
most of your takes here sound like they're from somewhere around 2016-2018