Live data from Hacker News

How we built a serverless SQL database

cockroachlabs.com

71–80 of 122 posts

Re: How we built a serverless SQL database

#72

> 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…

But wouldn't you agree that the initial architecture is really important; It should be at least designed with scaling in mind? Since it can get difficult changing things afterwards.

Re: How we built a serverless SQL database

#73
post #58

> 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…

The answer is unfortunately less clear cut. Particularly if you assume that whoever is tasked with scaling this hypothetical DB doesn't know what they are doing a-priori. The following questions are likely to come up 1) My t3.xl DB is down, how much bigger can I make it? 2) My r3.24xl DB can only handle 100 TPS and now my site is down, what can I do? 3) My 2x r3.24xl DB cluster costs a lot of money, Are other solutio…

Why would you assume that the person responsible for a thing doesn't know what they're doing?

Re: How we built a serverless SQL database

#74
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.

I only skimmed the article, but... is Cockroach serverless multi region?

Re: How we built a serverless SQL database

#75
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.

How does this serverless offering compare to Fauna?

Re: How we built a serverless SQL database

#76

How does this compare to Snowflake?

Snowflake is OLAP and billed based on usage time + storage. This looks like it’s a regular OLTP SQL DB and pay by request.

I see. Looking at the docs, the pricing for storing data is measured in Gigs (I think $1 per gig per month) - not Tb. This makes me think it is intended for smallish data.

I have a database now with 40 Tb - this would cost $40k a month just to store!

Re: How we built a serverless SQL database

#77
post #69
post #53

Earlier quoted context omitted.

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…

In the case you mention, you've made a tradeoff to defer developing an in-house solution for supporting a potential future pattern of production traffic, and that can be a huge accelerator.

Further, once you're experiencing the types of success that demands a superior solution the priority to invest in such a solution is clear.

It isn't "lock-in" - there's enough experience and capability in the market to solve those problems _once you have to_. Solutions like this let you decide whether the right time is at start-up or scale-up.

Re: How we built a serverless SQL database

#78
post #74
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.

I only skimmed the article, but... is Cockroach serverless multi region?

The reply below says yes:

https://news.ycombinator.com/item?id=29005597

Re: How we built a serverless SQL database

#79
post #58

> 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…

The answer is unfortunately less clear cut. Particularly if you assume that whoever is tasked with scaling this hypothetical DB doesn't know what they are doing a-priori. The following questions are likely to come up 1) My t3.xl DB is down, how much bigger can I make it? 2) My r3.24xl DB can only handle 100 TPS and now my site is down, what can I do? 3) My 2x r3.24xl DB cluster costs a lot of money, Are other solutio…

> The answer is unfortunately less clear cut. Particularly if you assume that whoever is tasked with scaling this hypothetical DB doesn't know what they are doing a-priori.

The answer is very clear-cut:

Work with professionals.

Re: How we built a serverless SQL database

#80

> 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…

During a technical interview many years ago, I commented that the system architecture didn't scale.

The interviewer responded "When that matters, I won't even be managing the person whose problem that is."

Post reply on HN