6 ms·
It would be interesting to known why a standard boring RDS setup wouldn’t solve their problem completely. In fact I would be more interested to understand that
by statictype 5y ago
It would be interesting to known why a standard boring RDS setup wouldn’t solve their problem completely. In fact I would be more interested to understand that than the actual details of sqlite tailing.
(I think the reason they gave was vendor lock-in, but apart from that, I didn’t understand why it wouldn’t be adequate)
- tptacek 5y agoOne obvious reason not to use RDS is wanting disk-local caches of information replicated from a single leader, rather than having every single machine in your fleet calling out to an external service on every read. That's certainly why we're not considering Postgres in our infrastructure, even though managed Postgres is a product we in fact offer. We use Postgres! It's the backing state for our API, and an important source of truth in our architecture. Postgres is a great way of serving a GraphQL API. It is not necessarily a good way to back an infrastructure service.
- statictype 5y agoMakes sense once you think of Tailscale as an infrastructure-level service and not just an app. Thanks
- throwdbaaway 5y agoSounds like postgres listen/notify could be viable for your high-read-low-write use case? Or it is not scalable enough for the fleet size?
- tptacek 5y agoThat's still all your infrastructure components calling out to an external service on every read --- and for what advantage? This isn't an app server; it's an infrastructure component, running (I don't know about Tailscale here, but we use SQLite in similar uses cases) on potentially hundreds or thousands of machines.
- throwdbaaway 5y agoNo, you don't need to make any network call on every read with listen/notify. It will essentially be a local cache, working the same way as etcd watcher, using one postgres connection per machine.