Earlier quoted context omitted.
That's rude. It's a shameless plug and I'm happy I have discovered that project thanks to that shameless plug
[flagged]
[dead]
Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
21–30 of 31 posts
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#22Hey this is amazing! I see the sqlite db is replicated but how does it handle multiple instances as writers? Curious if the underlying sqlite engine is syzy or if there's other restrictions to be aware of
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#23The warm-pool tree (kernel → base runtime → app) with CoW memory pages is a nice design — that's the part that makes 3ms believable rather than marketing.
Question on the shared SQLite: with multi-writer CRDT replication and eventual consistency, how do you handle operations that need global agreement — unique usernames at signup, or "did my vote count exactly once"? The HN-clone demo has both auth and voting, so I'm curious whether the HTML app model resolves those at the CRDT layer or accepts last-write-wins and tolerates the edge cases.
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#24Hey this is amazing! I see the sqlite db is replicated but how does it handle multiple instances as writers? Curious if the underlying sqlite engine is syzy or if there's other restrictions to be aware of
Thanks! Yes, the write-replication part is syzy, which hooks into the standard unmodified sqlite engine that reads and writes normal sqlite db files locally - syzy just keeps multiple instances in sync by capturing writes and applying them elsewhere.
It handles multiple writers by capturing changes as logical operations, then resolving conflicts in a globally-deterministic order based on their contents based on a CRDT model.
There are some limitations (see https://github.com/wjordan/syzy/blob/main/sqlite/docs/LIMITA...), mostly around primary keys (they have to be non-NULL) and UNIQUE constraints (there's some subtle differences in behavior between nullable and NOT NULL uniqueness). But in general, the goal is for all of SQLite, DML and DDL, to just work normally!
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#25Built in replicated database and filesystem is pretty rad. Fly leaves this as an exercise for the user.
You should license the backend to enterprises that want a cheaper/lighter weight option to kubernetes for the surge of agentically coded internal apps.
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#26> Billed per-second on actual resources consumed, … memory tracks active resident pages
Wait, are you saying it has dynamic vertical scaling of RAM?
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#27> Billed per-second on actual resources consumed, … memory tracks active resident pages Wait, are you saying it has dynamic vertical scaling of RAM?
Pretty much! It's not dynamic memory hotplug or resizing, just dynamic billing. Usage is based on the actual RSS used by the app so you can think of the VM's defined size as just a limit, for both CPU and RAM. This means you don't have to spend time profiling and right-sizing instances to optimize costs, just make your application fast and efficient and don't worry about it!
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#28Two questions about the fork boundary. The snapshot is taken once when the process calls listen, so every later instance is a clone of the same frozen memory image, and anything seeded during init is identical across every clone in every region. That is exactly what the Linux vmgenid driver exists for, and it is why Lambda SnapStart had to ship explicit reseeding guidance. I could not find entropy, RNG or reseed anyw…
LLM comments are not allowed.
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#29A replicated SQLite is very cool! One question I would have is why expose that as the storage instead of the platform providing a managed storage API? I guess I might be concerned about replication lag and complexity for consumers with the replicated SQLite.
Is it to have more sympathy for LLMs? More 1:1 with a local dev environment?
Re: Show HN: Kedge – Full-stack cloud with forkable VM snapshots and global SQLite
#30Two questions about the fork boundary. The snapshot is taken once when the process calls listen, so every later instance is a clone of the same frozen memory image, and anything seeded during init is identical across every clone in every region. That is exactly what the Linux vmgenid driver exists for, and it is why Lambda SnapStart had to ship explicit reseeding guidance. I could not find entropy, RNG or reseed anyw…
LLM comments are not allowed.
certainly sounded like one of