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!

Right now it is 1:1, but we're hearing that people would like to share one database among many repls. Something you can do right now is spin up a repl and have other repls talk to it over HTTP to share a database: https://docs.repl.it/misc/database#how-do-i-share-a-database...

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.

This is standard operating procedure for many companies in the VPS and server market. It's to ensure that they can keep customers updated even if all of their infrastructure goes down. Some companies take it a step further and put their status page on a completely separate domain, e.g. DreamHost's http://www.dreamhoststatus.com

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.