Apparently they've deprecated Postgres support and now only recommend sqlite as the storage backend. I have nothing against sqlite but to me this looks like Tailscale actively signaling what they think the expected use of headscale is.

▲

ghrl 4 hours ago | parent | next [-]

https://headscale.net/stable/about/faq/#scaling-how-many-cli...

> Scaling / How many clients does Headscale support? > It depends. As often stated, Headscale is not enterprise software and our focus is homelabbers and self-hosters. Of course, we do not prevent people from using it in a commercial/professional setting and often get questions about scaling. > Please note that when Headscale is developed, performance is not part of the consideration as the main audience is considered to be users with a modest amount of devices. We focus on correctness and feature parity with Tailscale SaaS over time. [...] > Headscale calculates a map of all nodes that need to talk to each other, creating this "world map" requires a lot of CPU time. When an event that requires changes to this map happens, the whole "world" is recalculated, and a new "world map" is created for every node in the network. [...] > Headscale will start to struggle when [there are] e.g. many nodes with frequent changes will cause the resource usage to remain constantly high. In the worst case scenario, the queue of nodes waiting for their map will grow to a point where Headscale never will be able to catch up, and nodes will never learn about the current state of the world.

I find that quite interesting and it is one of the reasons I've not really considered trying out Headscale myself.

	▲	TheCraiggers 3 hours ago \| parent [-]
		Why? Makes perfect sense to me. Designing a product with a specific use case in mind is good. When you've got the limited resources of am open source volunteer project, trying to solve every problem is a recipe for burnout. If it can even be done.

▲

jscd 3 hours ago | parent | prev | next [-]

Tailscale itself only uses sqlite[1], so I’m not sure if that really holds in this case.

[1]: https://tailscale.com/blog/database-for-2022

▲

markonen 2 hours ago | parent [-]

TIL! My problem with them requiring sqlite was that I assumed it would make a high availability setup either hard or impossible. Maybe that's not true, but definitely off the beaten path for headscale.

	▲	xanthor an hour ago \| parent [-]
		Headscale only supports a single control node.

▲

athrowaway3z 4 hours ago | parent | prev | next [-]

I dont understand what these two have to do with anything? The db-use is almost trivial, and SQLite can be embedded. Why would we want wasted effort and configuration complexity on supporting postgres?

▲

flammafex 4 hours ago | parent [-]

[flagged]

▲

prmoustache 4 hours ago | parent [-]

With that kind of logic you wouldn't need headscale and would just ask your favorite LLM to write a similar tool for your with your own requirements and nothing else.

	▲	flammafex 3 hours ago \| parent [-]
		No, not really necessary to extrapolate the logic any further. You have deemed a very specific and focused task as "wasted effort." So the logic leads to putting in the effort you do not find "wasteful" and outsource the remainder to the LLM do this very specific thing.

▲

khana 2 hours ago | parent | prev | next [-]

[dead]

▲

tucnak 3 hours ago | parent | prev [-]

Yeah, Headscale people don't hide that it's a toy. I didn't get a homelab full of datacentre-grade equipment because I want to use toy, nonscaling solutions with vastly incomplete feature sets, but for the exact opposite reason.

On a different note; the HN obsession with SQLite these days is getting a bit tiresome.