CockroachDB, Serverless, and RESTful API over HTTP

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 :slight_smile:

(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.