Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we built a serverless SQL database

cockroachlabs.com

Post reply on HN
Print view View original

91–100 of 122 posts

Re: How we built a serverless SQL database

#91

Post by WatchDog »

andydb wrote: post #70
WatchDog wrote: post #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…

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

I guess two main use-cases come to mind, providing isolated multi-tenant saas services, also easily creating test/dev environments.

In a similar vein to how you have made cockroach multi-tenant, not too long ago I worked on building a multi-tenant sass version of a business intelligence app. The app uses a relational DB, initially we used separate schemas on the same db cluster, but we had problems with noisy neighbors, as well as concerns about it's security.

We later opted to run dedicated database clusters for each tenant, however it greatly increases the marginal cost, and makes it difficult to provide a free tier of service, which is a valuable way to gain new customers.

Re: How we built a serverless SQL database

#92

Post by yla92 »

andydb wrote: 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.

> Each node runs in its own K8s pod, which is not much more than a Docker container with a virtualized network and a bounded CPU and memory capacity. Dig down deeper, and you’ll discover a Linux cgroup that can reliably limit the CPU and memory consumption for the processes. This allows us to easily meter and limit SQL resource consumption on a per-tenant basis.

Nice use of K8s here and overall a great post! This is not related to CockroachDB but related to kube and cgroup. I am wondering if you guys have faced this infamous CPU throttling issue[0] when you guys were doing the metering and limiting.

[0] : https://github.com/kubernetes/kubernetes/issues/67577

Re: How we built a serverless SQL database

#93

Post by andydb »

WatchDog wrote: post #91
andydb wrote: post #70

Earlier quoted context omitted.

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

I guess two main use-cases come to mind, providing isolated multi-tenant saas services, also easily creating test/dev environments. In a similar vein to how you have made cockroach multi-tenant, not too long ago I worked on building a multi-tenant sass version of a business intelligence app. The app uses a relational DB, initially we used separate schemas on the same db cluster, but we had problems with noisy neighbo…

I think you're right on target with the multi-tenant SAAS services. They often suffer from the "long-tail" problem, where the tiny customers without much usage cost too much to host. And of course, that's one of the big problems the CockroachDB Serverless architecture solves.

There's no technical reason why CockroachDB Serverless couldn't support that scenario - it's more of a product/business/sales question. I think we'd be very open to talking with companies that have that kind of problem to solve.

Re: How we built a serverless SQL database

#94

Post by webmaven »

YZF wrote: post #86
emilsedgh wrote: post #82

Earlier quoted context omitted.

Isn't that the right mindset?

This will be somebody else's problem? Ehm, no it's not. - When the bridge collapses I'll be managing someone else. - When they find out this airplane has critical design flaws I'll be managing someone else. - When this software I'm working on is hacked I'll be managing someone else.

Your examples aren't equivalent. You're comparing the failure of a prototype or proof-of-concept under stress to the failure of production models under expected conditions.

The real risk you're incurring by deploying a prototype to production until traction is demonstrated and scaling becomes an issue is that deferring the design of the 'real' system risks succumbing to second-system syndrome and prematurely trying to make it a 'platform'.

Roughly, the first version just has to work, the second has to scale, and the third (assuming you get there that soon) is the one that starts needing to be refactored/generalized into various reusable subsystems.

Re: How we built a serverless SQL database

#95

Post by amitkgupta84 »

andydb wrote: 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 will you handle PrivateLink and VPC Peering connections into customer VPCs/Vnets with the multitenant architecture?

Re: How we built a serverless SQL database

#96

Post by truetraveller »

phoboslab wrote: post #37

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

Side note: this guy is Dominic Szablewski, author of the amazing ImpactJS, JSMpeg, QuakeVR. Probably a 10x developer. He rivals Fabrice Bellard of ffmpeg fame. Check out his site: https://phoboslab.org/

Re: How we built a serverless SQL database

#97

Post by jayd16 »

dcposch wrote: post #53
phoboslab wrote: post #37

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

k8s lets you put multiple deployments on virtualized hardware in a cloud agnostic/consistent way. You can do all that on one machine. Even if you're running a single instance deployment you still probably want at least two environments. K8s isn't without value in that respect.

Re: How we built a serverless SQL database

#98

Post by webmaven »

emilsedgh wrote: post #88
YZF wrote: post #86

Earlier quoted context omitted.

This will be somebody else's problem? Ehm, no it's not. - When the bridge collapses I'll be managing someone else. - When they find out this airplane has critical design flaws I'll be managing someone else. - When this software I'm working on is hacked I'll be managing someone else.

It's not a matter of who's problem it is. It's just that a scale-able architecture in most cases is a premature optimization. When building a product, scalability is only one aspect. And in case of most startups and companies, amongst the smaller ones. I personally interview a lot of people and if they start proposing microservices or k8s or anything trendy like that (before having context), I consider it a negative…

> Security is not a premature optimization

There are plenty of situations where decent security is a premature optimization too. For example prototypes or proofs-of-concept that are only intended to demonstrate or benchmark a capability. The sort of thing where, even if you did insist on making it 'secure' the username/password would be admin/admin.

Re: How we built a serverless SQL database

#99

Post by jayd16 »

unobatbayar wrote: post #72
phoboslab wrote: post #37

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

Sure if "in mind" includes realistic capacity planning.

Re: How we built a serverless SQL database

#100

Post by earleybird »

phoboslab wrote: post #37

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

And the rational that validates this was written back around 2006[0]

[0] https://web.archive.org/web/20090306191715/http://www.my-idc...

Post reply on HN