Live data from Hacker News

How we built a serverless SQL database

cockroachlabs.com

61–70 of 122 posts

Re: How we built a serverless SQL database

#61
post #13

Earlier quoted context omitted.

You might like what we’re building at Splitgraph: https://www.splitgraph.com/connect

Oh wow, very relevant indeed! I guess I thought ephemeral DBs would be better so that a user’s expensive query wouldn’t bog down the db for other users. And rather than just limiting them, enabling them to do whatever queries they could with pg running locally

This is something we are currently building at Klarrio on top of YugabyteDB.

We have opted for YugabyteDB table spaces to solve the isolation problem. We allocate a number of dedicated tablet servers to a tenant so that their db objects are close to each other. YugabyteDB executes queries only on those tablet servers where the data relevant to the query is. A resource heavy tenant doesn’t have an impact on other tenants. It’s not really “serverless” but does seem to solve the problem at a cost.

Tenants receive complete databases with grant permissions so they can do as they please.

Because YugabyteDB uses Postgres 11 under the hood, we have an additional sanity layer in form of a Postgres process utility hook which prevents the tenant from escaping the sandbox.

Re: How we built a serverless SQL database

#62
post #44

Earlier quoted context omitted.

Unfortunately, easy to hit that with say GraphQL where each client request can resolve to dozens of db selects vs a single hand written/tuned SQL select.

Maybe that's a good reason to avoid GraphQL then?

That's not the reason, there are many but this a nice feature where a client can send one request and it will resolve internally (so less client side requests), you can request only the fields you need and it's easier when hitting multiple micro services.

Now you get into the issues of tracing, request failures and retries, payload size (only json? really..) etc.

But I do agree that a super optimized sql for a a specific purpose has it's performance benefit

Re: How we built a serverless SQL database

#63
I think some of the value of Cockroach Serverless may depend on what the RUs (request units) map to. Looking at some competitors...

Google says that Cloud Spanner should get you around 7,000 read queries per second and 1,800 write queries per second for $650/mo. If a simple indexed read is 1 RU, $650 on Cockroach Serverless would get you around 2,500 reads/second. Of course, I think it's completely reasonable for a Serverless option to cost a bit more given that you'd need to over-provision Cloud Spanner (even if you smartly increased/decreased the amount of compute allocated based on demand).

Planet Scale charges $15 per 100M rows read and $15 per 10M rows written. If an RU is a row read, then Cockroach Serverless would be $10 per 100M rows read. If a write takes 10 RUs, Cockroach would cost $10 per 10M rows written. Both of those would be less than Planet Scale's cost - but it's possible that a row read will cost more than 1 RU. Let's say that an indexed lookup of a row costs 5 RUs. Then Cockroach Serverless starts costing 3.3x more than Planet Scale.

AWS DynamoDB charges $1.25 per million write request units and $0.25 per million read request units. If I can get 10M reads from Cockroach Serverless for $1 and 4M reads from DynamoDB for $1, Cockroach's pricing looks pretty good. Of course, if I need 5 RUs to do an indexed read, the pricing doesn't look as good anymore.

I do respect Cockroach Labs somewhat ambiguous description here. Planet Scale's $15 per 10M rows written feels like something that could become bad. What if I define hundreds of indexes on the table? What if I'm inserting very large blob/text columns that are 50MB in size? Likewise, what if I index no columns and end up forcing a full table scan, but only 10 rows are returned? Do they consider that I "read" 10 rows or "read" all the rows in the table? If it's the former, I'm putting a lot of strain on their system without paying for it. If it's the latter, I'm going to just define indexes that might not be worth it if I were paying for the IO needed to do all that writing.

Still, it would be nice if Cockroach Labs offered some indication of what could be accomplished with 1 RU. "An indexed read of 1 row or an indexed read of a few rows in sequence; for example, 'SELECT * FROM people WHERE age > 18 ORDER BY age, name LIMIT 10' where there exists an index on (age, name)." That would let me know what to expect. "A write of a row under 4KB in size with no secondary indexes will cost 3 RUs; expect secondary indexes to increase the cost by 1 RU each" would give me an idea of what's going on.

I think there are definitely cases that one can't easily enumerate. For example, "UPDATE people SET age = 18 WHERE EXISTS (SELECT * FROM legacy_info WHERE people.id = legacy_info.people_id AND legacy_info.is_adult = true)". That's potentially going to require lots of stuff that's harder to predict. However, at this point I don't know if an indexed read of a row costs 1 RU or 10 RU. If an indexed read of a single row costs 1 RU, if I read 10 rows sequentially will that mean 10 RUs or will 1 RU have enough IO to cover that since they're sequential (or will the billing just over-charge since there's tangibly more rows and that's easy to explain)?

I think a decent amount of the value depends on the pricing and it's hard to judge that right now.

One thing I will note is that the storage seems expensive. It's slightly cheaper than Planet Scale, but a lot more than the $0.30/GB of Cloud Spanner or the $0.23/GB of FaunaDB or $0.25/GB of DynamoDB. I've been wondering a bit about the storage pricing of Planet Scale since $1.25/GB seems expensive. Cockroach Serverless is coming in at $1/GB which also seems expensive compared compared to alternatives. If Cloud Spanner is basically offering a third the price, is the "Serverless" flexibility worth it given that Spanner can be scaled up/down pretty easily in very granular increments.

Actually, one thing that could be useful might be noting how many request units per month one of the dedicated instances would have. A 2 vCPU CockroachDB instance costs $350-400. Would that be 4 billion request units per month (assuming you were fully utilizing the box)? Would it be more like 15 billion request units per month since you're presumably paying a premium for the Serverless flexibility?

Re: How we built a serverless SQL database

#64
post #26
post #3

Earlier quoted context omitted.

What's your elevator pitch for why my organization should use CockroachDB Serverless vs. something like AWS Aurora Serverless, particularly if we're already relatively invested in the AWS ecosystem?

Oh boy, I'm an engineer, but I'll do my best to pretend I'm on the sales or marketing team for a minute... First of all, CockroachDB Serverless is available on AWS, and should integrate quite well with that ecosystem, including with Serverless functions offered by AWS Lambda. Here are a few advantages of CockroachDB Serverless that Aurora will struggle to match (note that we're still working on Serverless multi-regio…

8. Online upgrades.

Re: How we built a serverless SQL database

#65

> If you’ve created a database before, you probably had to estimate how many servers to use based on the expected traffic. The answer is "one". If you have less than 10k req/s you shouldn't even start to think about multiple DB servers or migrating from bog-standard MySQL/MariaDB or Postgres. I will never understand this obsession with "scaling". Modern web dev seriously over-complicates so many things, it's not even…

I disagree. Even the simplest master-slave setup bound to cause an outage once or twice.

Now, if you setup your DB using public cloud's flavor of PostgreSQL... That's a different story.

Re: How we built a serverless SQL database

#66
This offering seems a lot more compelling than the serverless databases offered by AWS directly.

At least if cost and scaling to zero is important to you. Dynamodb addresses the cost issue, but it's so painful to use, and is unsuitable for a lot of use-cases. Aurora Serverless takes 30 seconds to cold-start, so it's also usually a non-starter, other than for batch type workloads.

So great work, but I have a couple of questions:

Any plans to support AWS privatelink? I played around with this a bit, and it seems you need to connect to it over the internet which isn't always ideal.

Will there be a limit on how many free databases you can create? I think there are some valid use-cases where one might want to create a bunch of them, but I would be scared to do this at the risk of being kicked off your platform for abuse.

Re: How we built a serverless SQL database

#67
post #2

To any who might see this, I'm the author of the blog post, and led the engineering team that built CockroachDB Serverless. I'll be monitoring this thread in case there are any questions you'd like to ask me about it.

Can I connect using an SSH tunnel (without the SSL cert)?

Re: How we built a serverless SQL database

#68
post #13

Earlier quoted context omitted.

You might like what we’re building at Splitgraph: https://www.splitgraph.com/connect

Oh wow, very relevant indeed! I guess I thought ephemeral DBs would be better so that a user’s expensive query wouldn’t bog down the db for other users. And rather than just limiting them, enabling them to do whatever queries they could with pg running locally

The query layer is composed of ephemeral Postgres instances that get created on-the-fly. These instances either proxy to live data via FDW, or they lazily download the columnar fragments necessary to resolve a query. This is meant to perform as a horizontally scalable caching layer for shared queries. For more optimized/predictable use-cases you can “check out” a version of a data image ahead-of time. In this case you use the `sgr` command line tool to load the objects of an image into a Postgres database that you can then scale vertically as normal.

Our site is a bit out of date — we’ve got a new marketing site coming shortly, and we’ve gathered an all-star engineering team to take this to the next level. Stay tuned :)

(Or better yet if you want a unified data stack for your team, please get in touch… we can load data from 100+ sources into versioned Splitgraph images, or we can index and proxy to existing data sources with federated querying).

Re: How we built a serverless SQL database

#69
post #53

> If you’ve created a database before, you probably had to estimate how many servers to use based on the expected traffic. The answer is "one". If you have less than 10k req/s you shouldn't even start to think about multiple DB servers or migrating from bog-standard MySQL/MariaDB or Postgres. I will never understand this obsession with "scaling". Modern web dev seriously over-complicates so many things, it's not even…

This is a good argument against running a k8s cluster when u don't need one, but not a good argument against this new serverless Cockroach product. Serverless is not just about auto scaling up from 1 to n, it's about autoscaling down from 1 to 0. If Cockroach provides a robust SQL DB at a marginal cost of ~$0/mo for small request volumes, that is a real value add over running your own pg server. Not having to deal wi…

Tradeoffs are tradeoffs.

In your k8s example, by running a k8s cluster when you don't need one, a cost you pay is the overhead.

In the Cockroach serverless case, costs that come to mind include vendor lock-in when you evolve a pattern of production traffic that is hard to migrate to other solutions, and security and compliance challenges due to the virtualized instances running on shared clusters. In many cases these tradeoffs may be worthwhile. My point is that looking at it only in the dimension of scaling up and down, doesn't tell the whole story. The OP doesn't talk about tradeoffs, so in the comment section we must.

Re: How we built a serverless SQL database

#70

This offering seems a lot more compelling than the serverless databases offered by AWS directly. At least if cost and scaling to zero is important to you. Dynamodb addresses the cost issue, but it's so painful to use, and is unsuitable for a lot of use-cases. Aurora Serverless takes 30 seconds to cold-start, so it's also usually a non-starter, other than for batch type workloads. So great work, but I have a couple of…

Our product roadmap will be heavily influenced by customer asks. So if there are things about CockroachDB Serverless that prevent you from using it (like requiring ingress through a public IP), we definitely want to hear about it.

Regarding a cluster limit, we currently allow up to 5 clusters per customer account. I'd like to hear what kind of use-cases you have in mind for having a lot more clusters. One I've thought about is CI runs, where you'd want dozens or hundreds of temporary clusters running at once, in order to run your testing in parallel.

Post reply on HN