Who do you think is the sweet spot user for Rivet? Anyone building any LLM app, or a certain kind (e.g. agents)? Is there a use case for which you'd advise against using Rivet?
I think it's people building tool-using agent applications.
We've been collaborating with several amazing teams over the past few months, who have been pushing Rivet in various ways. We used it for a chat interface at Ironclad, but we've seen companies like Bento and Willow integrate it with different UX paradigms.
The commonality seems to be that we are all integrating LLMs into an application, and want the LLM to somehow interact with that application (set up search filters, build a guide based on documentation).
Queries on DoltHub need to go to S3 to fetch all the chunks. This only works for databases < 1GB generally. You will get much better performance if you clone the database locally.
Great to see popular SaaS use cases commoditized and opened up like this. After product categories start to fossilize into a standard UX + features, the benefits of using an expensive vendor start to decrease.
In a lot of ways, having this be based on k8s provides a lot of flexibility and independence, and with k8s there's much less friction to providing computes with high locality relative to applications/users application code.
It's also the case that by staying with k8s we can take advantage of existing operational tooling, experience, and work, and can focus or development time on the important parts of this problem: runtime scaling, scheduling, and virtual machine management and not on cloud provider APIs and management.
In short, k8s gives us options that we like for the future, it's shortening the development cycle, and only getting in our way a below-average amount. At the same time--for the most part--we're building this with reasonable abstractions that would let us reuse our existing work if k8s becomes more trouble than it's worth.
Firecracker doesn’t support live migrations. There is a new project called cloud hypervisor and it showed a lot of promise, but we struggled to make it works and reverted to QEMU
As for k8s its an ongoing debate internally if the complexity worth the benefit. It helps us provision nodes but we have to fight it quite a bit too. It’s unclear we will keep it long term
I love DuckDB and am cheering for MotherDuck, but I think bragging about how fast you can query small data is really no different than bragging about big data. In reality, big data's success is not about data volume. It's about enabling people to effectively collaborate on data and share a single source of truth.
I don't know much about MotherDuck's plans, but I hope they're focused on making it as easy to collaborate on "small data" as Snowflake/etc. have made it to collaborate on "big data".
It’d be great to show the debugging experience in the video (in fact, I’d prefer seeing that over the breadth of features). E.g. what happens when there’s a syntax error in my sql query or the python code fails on an invalid input?
That tends to be the critical make it or break it feature when you’re writing code in an app builder.
Also I would assume different languages have different random() implementations which could contribute to the run time. So to make tests equal, you should not measure time to set up the array.
