DB seems like the main shortcoming in the stack for them. I don't want to deal with the limitations of D1. Seems like a serverless postgres setup a la Neon/Supabase would be a slam dunk.
I've used DO's quite a bit. I'm a big fan... however I find the database latency pretty hard to deal with. In the past 6 months I've seen upwards of 30s for little side projects running tiny (100's of kb) databases. Sometimes it's lightning fast... sometimes it's a disaster.
As a consequence I've had to build quite defensively - adopting a PWA approach - heavy caching and background sync. My hope is that latency improves over time because the platform is nice to work with.
Yeah, but then I'm heavily coupled to their proprietary infrastructure. Maybe a good thing for them, but a nonstarter for thinking about building a real business on, for me and many others I'd presume.
our open source system. We use this tool to serve a custom routing engine at day job. Handles 100req/s djikstra in a 2GB pod, due to precalculation of contraction hierarchies.
Doesn’t matter. The point is that DuckDB can operate well on a wide range of infrastructure and is well suited for operating in resource constrained environments.
The changelog is remarkable. Thanks to this team for creating such an amazing tool. It's genuinely the technology I've been most excited about in a long time. Makes the ergonomics of working with large data a joy and extremely fast.
How do you ascribe a revenue number like that based on one collection of changes in a huge system? Presumably there were a bunch of other features being released around the same time as it. Was there a lot of A/B testing around it?
reply