kochman

Good points, you're right: you have to be signed in for Database to work. We'll make this clearer. We'll also fix the code snippet copying. Thank you for giving it a try!

We did! Our infrastructure has some unique constraints around filesystem persistence. We use btrfs and regularly take snapshots of the repl's filesystem while someone is editing the repl. However, we don't take snapshots when a repl is only acting as a web server without anyone editing it, meaning that we would need a solution that lives outside of the repl's filesystem.

Keeping each database outside of the filesystem also gives us the flexibility to let people access the same database across multiple repls in the future.

I have lots of love for SQLite; early prototypes of Database were backed by it!

It's Postgres under the hood. The key-value service itself is Go and we run it on GKE alongside some of our other services.

Yep, that's the idea. If you had a user with ID 1, one scheme to get all her info could be storing attributes in keys such as:

  user:1:name
  user:1:email
  user:1:city

Then a prefix search for "user:1:" would get you the relevant keys for that user.

But you could also go another way and drop a JSON-encoded object in a single key and work with it inside your app, since that might be the fastest way to get something off the ground!

Hey HN! I’m a Repl.it engineer who’s been focused on bringing Database to life. Happy to read your comments and answer any questions you might have.

I don't like the trend of businesses becoming less and less easy to reason with. If an algorithm, or even a person, decides to cut you off, that's it. There's little recourse in situations like these.