Adam Kocoloski

That is an excellent topic. So we have, as a community said, Look, our goal here first and foremost is to try to look at all of the different parts of the existing API and make sure that this is a relatively non disruptive upgrade for our existing user base. That being said, It's incredibly tempting to look at some of the things that we can't do today in the couchdb API that we might be able to do in the future with the foundation DB storage layer. And, you know, as we have started having some of those conversations in the community that say, what could we do from a transactional perspective, you know, now that we have this underlying, strictly serializable storage layer that scales across multiple machines, what could we do that, you know, we don't do today, and nothing committed on that front right now. But I think more and more people are appreciating that like, there's a real interesting opportunity there. You also talked about actually exposing the foundation DB API. And I think that's a place where a lot of people go, they kind of look at it. So as this is this like a multi model kind of database where I can use the document API on the one side Graph API on the other side, I think what you find is that anytime you're working with foundation dB, when you're building a layer on top, if your goal is to build the best document layer possible, you're gonna make a number of design decisions that will be intention with something that says, hey, I'm trying to build a multi model database. Therefore, I'm going to create this completely generic data model under the hood that allows it to be accessed from different types of query languages and different types of API's. So I have I've looked at it and said, You know, I think the right way to think about this is foundation DB as an internal implementation detail. And then you know, you as a tool in our tool belt, under the hood, that allows us to deliver a great document database, and if over time, someone else should say, hey, I want to build a great graph layer over top of foundation dB, that makes the foundation DB project better. But I'm not a huge proponent of thinking that like foundation DB is the right level. abstraction to allow people to have a common data model that can be accessed by different types of API's and different types of query languages. I guess the last piece you said was, well, what about the foundation API API directly. And that was an interesting one, too. If you look at FTB, today, it's got this kind of very tight coupling between the client layer and the server layer. That is, you know, a very different experience than say, using couchdb REST API. The clients need to be kind of participating in the upgrade of the server. And they kind of need to be very cognizant of the version of the server that's running. And there's all kinds of details that go into that there is some talk in that world that talk around introducing a more stable API, g RPC API, or something of that nature that will allow for that kind of more direct exposure foundation dB. But that's not something that we as a product are really looking at. I think our view in couchdb is that couchdb is the kind of database that can be exposed directly as a cloud service that can be exposed, you know, powering web applications that has the kind of security model that has the kind of access control model that people need to have there. And FTB, frankly, just works at a lower level than that.