4 ms·

Just curious, if you feel comfortable sharing, what do you use as your database? I'd agree Postgres is not the right answer to every problem, but the documenta

by gen220 3y ago

Just curious, if you feel comfortable sharing, what do you use as your database? I'd agree Postgres is not the right answer to every problem, but the documentation of its failure modes and the mitigations thereof make it a "good" answer to "most" problems. I'm curious what the "problem" (in access pattern terms, doesn't have to be business terms) and "solution" (i.e. persistence technology) is in your setup!

jwr 3y ago
Sure. I use RethinkDB, which works well, but has been pretty much abandoned at this point. It's a good database, but it wasn't "in fashion" like many worse solutions were. I am working on replacing it with FoundationDB. I want to have a fully distributed database with strict serializable semantics (see https://jepsen.io/consistency https://jepsen.io/consistency), and there is very little out there that gets the job done. FoundationDB is really impressive and works really well. I'm worried that it isn't "fashionable", though. As for access patterns, I'm not sure if I understand the question, but I'll offer one thought: if you're writing an app, you don't need a "query language'. You'll quickly learn what your queries are, and the right approach is to restructure your data to fit your access patterns. Your "queries" will be written in your programming language of choice, not in the databases "query language". I feel that the idea of a "query language" is stuck in our heads back from the days when the boss would come and tell you to produce a custom report from the database. It's just not how app databases are used these days.
- gen220 3y ago
  Appreciate the glimpse! Should have elaborated, by access patterns I was referring to proportion of readers to writers, the distribution of load over time, the distribution of transaction sizes, so on. Although your discussion of query language is an interesting one – that the goal is essentially efficient (de-)serialization with "retrieval-from-other-process" costs that are minimal for your workload and subset of query space.

by gen220 3y ago

jwr 3y ago

Sure. I use RethinkDB, which works well, but has been pretty much abandoned at this point. It's a good database, but it wasn't "in fashion" like many worse solutions were. I am working on replacing it with FoundationDB. I want to have a fully distributed database with strict serializable semantics (see https://jepsen.io/consistency https://jepsen.io/consistency), and there is very little out there that gets the job done. FoundationDB is really impressive and works really well. I'm worried that it isn't "fashionable", though. As for access patterns, I'm not sure if I understand the question, but I'll offer one thought: if you're writing an app, you don't need a "query language'. You'll quickly learn what your queries are, and the right approach is to restructure your data to fit your access patterns. Your "queries" will be written in your programming language of choice, not in the databases "query language". I feel that the idea of a "query language" is stuck in our heads back from the days when the boss would come and tell you to produce a custom report from the database. It's just not how app databases are used these days.

gen220 3y ago
Appreciate the glimpse! Should have elaborated, by access patterns I was referring to proportion of readers to writers, the distribution of load over time, the distribution of transaction sizes, so on. Although your discussion of query language is an interesting one – that the goal is essentially efficient (de-)serialization with "retrieval-from-other-process" costs that are minimal for your workload and subset of query space.