I'm working on a database service that might help with a problem I've seen repeatedly: apps taking 3-10 seconds to load because data has to round-trip from us-east-1 (or wherever your backend lives).
The concept: a global sharded database, with shards deployed across 50+ edge locations, with Raft-based replication. Your data follows your users around the world. Reads and writes to the database happen in a nearby edge datacenter.
Example: Travel app user in Sydney currently waits seconds for itinerary to load (multiple 200ms round-trips to database in Virginia). With edge deployment, latency of database interactions will be down to 10-30ms.
Technical approach: a sharded global database, with SQLite for local storage, and 2PC for cross-shard transactions. PostgREST-compatible API from the device.
Background: I worked on distributed data systems at Google (Spanner) and Meta, so I'm familiar with the tradeoffs in global data distribution.
Before building an MVP, I'd love feedback from the HN community:
1. Is latency from centralized databases actually a pain point for your apps?
2. What use cases would benefit most? (mobile apps, real-time collaboration, IoT?)
3. What would worry you about moving data to the edge? (consistency, cost, complexity?)
4. Would you consider this vs. just adding a Redis cache layer?
Early documentation and details: sailwind.io
Happy to answer technical questions about the architecture.
Hi HN,
I'm working on a database service that might help with a problem I've seen repeatedly: apps taking 3-10 seconds to load because data has to round-trip from us-east-1 (or wherever your backend lives).
The concept: a global sharded database, with shards deployed across 50+ edge locations, with Raft-based replication. Your data follows your users around the world. Reads and writes to the database happen in a nearby edge datacenter.
Example: Travel app user in Sydney currently waits seconds for itinerary to load (multiple 200ms round-trips to database in Virginia). With edge deployment, latency of database interactions will be down to 10-30ms.
Technical approach: a sharded global database, with SQLite for local storage, and 2PC for cross-shard transactions. PostgREST-compatible API from the device.
Background: I worked on distributed data systems at Google (Spanner) and Meta, so I'm familiar with the tradeoffs in global data distribution.
Before building an MVP, I'd love feedback from the HN community:
1. Is latency from centralized databases actually a pain point for your apps? 2. What use cases would benefit most? (mobile apps, real-time collaboration, IoT?) 3. What would worry you about moving data to the edge? (consistency, cost, complexity?) 4. Would you consider this vs. just adding a Redis cache layer?
Early documentation and details: sailwind.io
Happy to answer technical questions about the architecture.