Much appreciated, I will check you out for my next project. Right now I'm not able to migrate as I'm trying to get an MVP up and running and have spent a few days deeply integrating w/ Supabase.
What are your core value prop differences between your service and sb? Just curious how I should think about your offering compared to what I'm familiar with.
We work with supabase - so your DB still deploys out to them, but we cache queries in memory so they're significantly lower latency. Since we're offloading reads, we also help handling traffic spikes, lower costs, etc.
Ah gotcha, that makes sense. My little hobby app has no need for any perf optimizations and I’m trying to minimize the surface area of technologies I incorporate.
I’ll keep you in mind for anything that does require performance! Currently I’m doing about 5 requests per day to the db layer, all from my dogfooding. With a very simple data model.
ReadySet is a new database cache engine that speaks SQL and automatically handles cache eviction by listening to your database's replication stream. Your application issues the same queries as before, they're just blazing fast and cost less.
We have openings across the stack:
- Rust engineers for our core dataflow engine.
- Front-end engineers and a Product Designer for our query analytics and cloud UI.
- Cloud engineers to build out our cloud-hosting service.
If you're interested, shoot me an email: greg@readyset.io
Hey, PM @ ReadySet - fair points, and thanks for checking us out.
We've been in pretty heavy development and have been heads down on getting ReadySet into your hands as quickly as we could. We'll be doing a major documentation pass soon which will have more info about clustering, etc.
I was just looking this up and it's correct, they don't cache queries (if they do, it's a separate feature), they only manage query planning in ways that make them faster.
Even CochroachDB doesn't do query cache, only query planning is cached. [0] [1]
