Will CockroachDB ever provide another type of API, such as a RESTful one over HTTP, to query a database? We’re interested in using Cloudflare Workers, but I don’t think it supports APIs over a TCP connection.
Lastly, are there plans for a managed serverless offering of CockroachDB? I’ve recently read a blog post about how a client managed to do this with AWS, but what about a global cross-cloud solution managed by CockroachDB?
Check out CockroachCloud 
https://cockroachlabs.cloud/
(Note: It doesn’t support cross-cloud setups yet)
Yep, we’re already aware of CockroachCloud, but as I understand you don’t automatically scale hardware based on usage. I’m talking specifically about how Aurora Serverless or FaunaDB work. Our product has highly unpredictable traffic patterns and there are clear peak-time and off-peak traffic patterns. Using a serverless model, I’d expect a pay-for-what-we-use model.
Lastly, any thoughts on providing an API over HTTP?
Hi @stexxart,
We are working on automatically scaling hardware based on usage, similar to how Aurora Serverless or FaunaDB works. And this would be pay as you go based on usage rather than on the hardware selected. We expect to have an MVP of this around summer of this year. If you’re open to it, would love to have you as beta customer for the the serverless offering in the summer.
A first step to enabling pay as you go, auto scaling serverless offering is the beta of a free forever tier in CockroachCloud that we released just yesterday. Would love to hear your feedback on it - it should be available in your Cloud account today.
Finally, we are also working enabling APIs to support CI/CD pipelines and other use cases to create/scale and delete clusters without going into the UI itself. I don’t have a firm date on when that will be available but it is a priority for the first half of this year.
The question was about restful API for cockroackdb and not about auto scalability. Currently we can only access CDB via Postgres protocol, is there any plan to provide access to CDB via rest APIs?
No plans at the moment, no. It is my personal hope that Cloudflare will partner with us and figure out together how to make CRDB accessible from Workers, and perhaps more generally from wasm environments. So far these discussions haven’t materialized.
See if the workarounds here help at all.
It’s much easier to provide a rest API endpoint for executing SQL statements. I would request you to consider adding this feature.
Noted, we’ll keep it in mind and see if it comes up more.
Would something like restsql be a possible workaround?
No, restsql is not a solution.
A built-in solution will give CDB an edge over other relational databases and not only allow developers to use CDB with cloudflare but it would also be possible to execute queries directly from front end application. No need to create your own API server.
CDB can expose a /login endpoint for accepting the user credentials and sending a jwt token. The client will send the token in header for each request for access control. The second /query endpoint can be used to execute a query and return result as JSON.
Other databases like flureedb and terminusdb are using the same method. Specially flureedb has a great support for access control and running queries directly from front end applications.
This would certainly be nice to have. It would really strengthen a serverless offering and would enable building nice web experiences. I think there are a number of proponents of these ideas internally. However, there’s a heck of a lot to do generally. The answer is more that we’re not doing anything here imminently rather than we’re not interested in doing anything here at all.
Also, it’s not exactly clear what the right APIs and experience should be. I can’t see a strong reason other than operational ease of use to bundle this API directly into the cockroach binary. Because of that, I anticipate any movement in this direction will start with an external service and only get embedded straight into the database after its usefulness has been well validated.
The majority of cloud serverless infrastructure wouldn’t support this.
This would be perfect! That’s actually the exact use case I’m looking at. We’re currently working on a few products that work ideal on edge infrastructure. We want to use Cloudflare Workers but are limited from not being able to support TCP.
In this new serverless world, it’s a must have feature for any database to survive. There is a long list of all kind of databases now providing rest API to access data base via http.
CDB already supports role based access management and this will make allowing direct access from front end app to CDB very easy. CDB just needs to expose three endpoints /login, /query and /reset_token.
Full stack application development is hard. This feature is a great time saver and can reduce app development time to half, If we can access CDB directly from front end app. The goal of cockroach dB founders is to facilitate startups and this feature will help them a lot.
I once again request you to please reconsider your decision.
Another huge benefit of built-in support for rest APIs is low latency and reduced query time which means more responsive Applications and great user experience as front end app can talk to CDB directly.
I don’t understand how a REST API has any impact on latency. I feel almost certain that any REST implementation would just end up issuing SQL underneath. Even if it didn’t, I don’t follow how this REST would fundamentally provide any reduction in latency or query time.
We can reduce response time, If we allow front end apps to access CRDB directly as now client apps don’t need to talk to our own API server in the middle. There are many studies proving that increase in latency means loss in revenue and customers for online businesses.
Flureedb is a great example of allowing client apps to connect to database securely and directly. This simplifies the whole tech stack a lot.
Please check this article for further explanation of this idea.
Hi @Lakshmi,
it’s exciting to hear that the team is working on an auto-scaling, pay-only-for-what-you-use kind of model, that’s comparable to Aurora Serverless.
By the way, if you were to adopt scaling down to zero with such a serverless offering, the near-instant startup times of CRDB would be a major selling point of adopting CRDB.
Last I heard, the cold-start times of Aurora Serverless were in the 20+ (sometimes even 50+) seconds range. I’d imagine CRDB would do better
Here’s what I’m wondering: In your post you mentioned that you were expecting the MVP of this serverless offering in the summer. Is the estimate of delivering the MVP this summer still feasible, and will the MVP be made available to CRDB Cloud users?
Thanks!
Hi Michael,
The MVP will be made available to all CockroachCloud users, yes. If you’d like to early test even before we roll out the MVP widely, we’d love that - would be happy to give you a free serverless environment. Note that CockroachCloud Free which is available today to all users is the first iteration of our Serverless vision – the main difference is that there will be a paid version (in addition to the free).
Finally re: timeline, an early preview look is feasible in the August time frame, but we’ll probably make it more widely available around September.
Hi Lakshmi,
thanks for getting back to me. That sounds great! I’d love to be a part of the early testing process 
, and would be happy to provide feedback. Do I have to sign up for this somewhere, or will you reach out via a message in this forum?
About CockroachCloud Free (very cool product, by the way) being the first iteration of the upcoming MVP: When setting up a CockroachCloud Free instance, if I remember correctly, one has to select a region for the node.
For the upcoming MVP however, I would hope that this would no longer be the case though, right?
Use case: Let’s consider the idea of a startup that’s about to launch or is in its growth phase, where a new marketing complain is launched globally.
Now, let’s imagine that new user bases in different regions become active over night.
It would then make sense, as part of the new serverless MVP product offering, that (new) instances/nodes would become active in (new) regions closest to these new users, even if these regions hadn’t been configured yet, to ensure the lowest possible latency and best UX. 
The timeline sounds very promising and would work well for what I have in mind.
Looking forward to it!