mrkurt

25 ms·

301.
by mrkurt 4y ago
It's not common, which is stupid. We're banging that drum pretty hard though. Maybe you'll see a #1 ranked HN post about it someday. :)
302.
by mrkurt 4y ago
Yes. Yes it is.
303.
by mrkurt 4y ago
It does! "Get a to-go database" is already on the roadmap. :)
304.
by mrkurt 4y ago
There's nothing that's quite ready to look at for easy failover, but this is a big priority. We absolutely have to figure out failover during deploys. It's doable we just want to reduce the operational complexity as much as w
305.
by mrkurt 4y ago
We disagree, a little. I feel like that if you have multiple apps writing to the DB, Litestream is pretty close to making sqlite viable for a lot more apps.
306.
by mrkurt 4y ago
The answer is: yes, you do have to write through a single primary application instance. So far. The two important things here are: 1. Fly.io makes it really easy to write through a single primary application instance 2. There are ways to so
307.
by mrkurt 4y ago
Litestream does a couple of things. It started as a way to continuously back sqlite files up to s3. Then Ben added read replicas – you can configure Litestream to replicate from a "primary" litestream server. It's still limit
308.
by mrkurt 4y ago
This is how client apps use sqlite, yes. Single instance client apps. Litestream is one method of making sqlite work for server side apps. The hard part on the server is solving for multiple processes/vms/containers writing to one
309.
by mrkurt 4y ago
Yes. We (Fly.io) are buying a sqlite support agreement. We also send money WireGuard's way. I'm pretty sure Tailscale does too. We have also given OSS authors advisor equity. A couple of folks wrote libraries that were important t
310.
by mrkurt 4y ago
Tailscale raised a Series A two years ago. They've been doing fine as it was – running a venture funded, high growth startup. I am wary of investors wrecking incentives for founders but that ship sails when you raise an A round. They&#
311.
by mrkurt 4y ago
We do waive attack related charges. We're not interested in making money on bandwidth. We have a blog post with a few more details here: https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/ That said, bandwid
312.
by mrkurt 4y ago
If your goal was to get us to spend more money on bandwidth, you succeeded. Well done. We documented how to do this quite a while ago, though: https://fly.io/blog/we-cut-bandwidth-prices-go-nuts/
313.
by mrkurt 4y ago
"Only export your data with pg_dump" is one of those misfeatures that makes RDS mediocre. They don't really expose much of the power of the underlying DB.
314.
by mrkurt 4y ago
Yes, exactly.
315.
by mrkurt 4y ago
aiven.io is quite good. They went broad instead of deep, so they're not as good at Postgres as the Postgres specific companies. But they're probably better Postgres than a PaaS can build by themselves.
316.
by mrkurt 4y ago
RDS will manage replicas for you. But you can't run your own non-rds replicas.
317.
by mrkurt 4y ago
The 2022 answer is actually to bake the CDN into your PaaS. Requiring a whole separate CDN for static assets is complication no one needs in their life.
318.
by mrkurt 4y ago
RDS runs pretty well! It's just irritating to use. The good DBaaS give me a lot more power. This is true for Heroku PG, PlanetScale, Supabase, and Crunchy Data. Some of them let me fork a DB to run a PR against, some give me app level
319.
by mrkurt 4y ago
I think the most interesting part of this is the PaaS disaggregation. Heroku built an exceptionally good Postgres service. They could not have done that with multiple DBs. Even their redis is pretty meh. People like us (Fly.io) will end up
320.
by mrkurt 4y ago
Boy howdy do I agree with this. Filesystems are immensely handy. We (a sometimes competitor of Heroku) shipped persistent volumes very early and it's been amazingly empowering. The DX gets difficult, but we're ironing that out ove
321.
by mrkurt 5y ago
We all know plenty of engineers who want to build things for inappropriate scale. The company was a disaster, but part of building a disastrous company is hiring the engineers who want to make everything webscale and have no sense of pragma
322.
by mrkurt 5y ago
The thing about startup decisions is: most of them are "wrong". Or they start right and become wrong later. Successful startups aren't successful in spite of their wrong decisions, they're successful because they can cha
323.
by mrkurt 5y ago
I believe "quickly" means "quick for a human to do" in this case.
324.
by mrkurt 5y ago
Managed DBs have tremendous lock in. Just try migrating off RDS with zero downtime. You can't, because they've "managed" your ability to configure external replicas. Then built a whole brittle data migration service that
325.
by mrkurt 5y ago
sqlite is, like, the regular-est of the databases.
326.
by mrkurt 5y ago
The cost of complication is high. They're optimizing for simplicity. Both for low friction development and easy operation. sqlite is amazingly simple for local dev. Probably even simpler than a json file. High availability Postgres is
327.
by mrkurt 5y ago
This is what we do now, basically. We have a Nomad Device Plugin and create local LVMs. We also have plumbing to move these between hosts. It works pretty well, it's just very limiting. What we need is to be able to target machines to
328.
by mrkurt 5y ago
It's very different than Nomad! The basic model is direct "machine" management with very little orchestration. Machines are kind of like allocations, but more permanent. Some machines operations are slow, some are fast. Creat
329.
by mrkurt 5y ago
Soon! We're polishing up a platform engineer role now. It'll appear on https://fly.io/jobs/
330.
by mrkurt 5y ago
Mostly yes. There are some races, particularly when services are deleted. A delete hint is actually authoritative.

More ›