[0xbadcafebee]

You say you want to have a small database just for each control process deployment to be independent. But you need multiple nodes for etcd... So you currently have either a shared database for all control processes, or 3 nodes per control process, or 3 processes per control node, etc. Either way it seems weird.

I get that SQLite wouldn't work, but it also doesn't make sense to have one completely independent database per process. So I imagine you're using a shared database, at which poitlnt etcd starts to make more sense. It's just not that widely understood in production as sql databases, and has limitations which you might reach in a few years.

[chupy]

> It's just not that widely understood in production as sql databases, and has limitations which you might reach in a few years.

Reaching limitations in a few years and biting that bullet makes the difference between a successful startup that knows when and where to spend time innovating or a startup that spends all their time optimizing for that 1 million simultaneous requests / sec.

[0xbadcafebee]

It's not about optimizing for scale, it's about optimizing for velocity. I don't care if I can only get to 1K RPS. I care if my team and product can work quickly. You cannot work quickly later if you slap something together now and later realize, oh shit, we have to stop pushing features for a month so we can completely rebuild the backend and everything that depends on it.

It's the devil you know versus the devil you don't. SQL is a very well understood devil, so your plans around it will be reliable. I would argue that being able to accurately estimate future work is the most valuable business asset.