4 ms·

Regarding 1): choosing a software stack (or any part thereof) without a clear use case is a recipe for failure. What's the use case?

asah 7y ago
To be fair, often you don't have your requirements completely nailed beforehand, or they change midway through the project. That's why I choose Postgres: aside from extreme scale or latency, you can throw pretty much anything at it. Also, given expert advice, its performance degrades gracefully i.e. lots of easy ways to optimize and workaround issues. Example: pg's type system is insanely flexible incl native support for high speed JSON, latlng, geometry, and more - and types are "batteries included" incl matching, inspection/extraction (e.g. JSON navigation), conversion, concurrency and concurrency control, ACID recovery, replication, etc. For example, it's one way line of code to create an index on the results of a JSON navigation expression whose result is then converted to another datatype e.g. timestamptz. Performance is then 100x+ on queries that use that expression. Pg datetime handling is also world class incl timezones and conversion, query and manipulation functions. Want the records from last Tuesday across timezones, given data in seconds-since-the-epoch? The SQL is shorter than in English.
- yen223 7y ago
  If the requirements are still up in the air, then I would aim to use the simplest, most evolvable solution. This to me means no database.
  - majewsky 7y ago
    If the requirements are still up in the air, but you know that you're going to be storing some data, definitely go with a database, even if just a single SQLite file. Using plain files means figuring out the file format, which turns into a huge mess when requirements get tacked on later. The other option would be to store a JSON file or a bunch of JSON files in a directory, at which point you're building a shitty version of either SQL or MongoDB instead of focusing on your business logic.
    - yen223 7y ago
      The grandparent comment is right about one thing: you need to figure out what your use case is, in order to make a good judgment call. “Some data” can mean a lot of things. Transactional data? Sure, get a sql database in. Images, video, or plain json documents? SQL databases are a poor fit there. One should also consider if they even need to manage data persistence. I’ve had success using Google Sheets as the backing data storage for a prototype. Below a certain scale, it is a lot easier to visualise and manipulate data in a spreadsheet than through a sql client.
      - Arkanosis 7y ago
        This. Answer “pg!” without any clue of what the objective is, and you'll end up with surprises like “oh, you know, this is for a revolutionary concept where people can check in their source code at different stages of development, so that they have a history of their changes and can restore an older version if needed” or “hey, we've followed your expert recommendations but now we're facing some availability issue after a link to our shiny new search engine made the front page of HN and Slashdot”. Migrating from pg to git or SOLR is not really enjoyable, and you can't reuse much of what you've done (unlike when migrating one SQL database to another).

asah 7y ago

To be fair, often you don't have your requirements completely nailed beforehand, or they change midway through the project. That's why I choose Postgres: aside from extreme scale or latency, you can throw pretty much anything at it. Also, given expert advice, its performance degrades gracefully i.e. lots of easy ways to optimize and workaround issues. Example: pg's type system is insanely flexible incl native support for high speed JSON, latlng, geometry, and more - and types are "batteries included" incl matching, inspection/extraction (e.g. JSON navigation), conversion, concurrency and concurrency control, ACID recovery, replication, etc. For example, it's one way line of code to create an index on the results of a JSON navigation expression whose result is then converted to another datatype e.g. timestamptz. Performance is then 100x+ on queries that use that expression. Pg datetime handling is also world class incl timezones and conversion, query and manipulation functions. Want the records from last Tuesday across timezones, given data in seconds-since-the-epoch? The SQL is shorter than in English.

yen223 7y ago
If the requirements are still up in the air, then I would aim to use the simplest, most evolvable solution. This to me means no database.
- majewsky 7y ago
  If the requirements are still up in the air, but you know that you're going to be storing some data, definitely go with a database, even if just a single SQLite file. Using plain files means figuring out the file format, which turns into a huge mess when requirements get tacked on later. The other option would be to store a JSON file or a bunch of JSON files in a directory, at which point you're building a shitty version of either SQL or MongoDB instead of focusing on your business logic.
  - yen223 7y ago
    The grandparent comment is right about one thing: you need to figure out what your use case is, in order to make a good judgment call. “Some data” can mean a lot of things. Transactional data? Sure, get a sql database in. Images, video, or plain json documents? SQL databases are a poor fit there. One should also consider if they even need to manage data persistence. I’ve had success using Google Sheets as the backing data storage for a prototype. Below a certain scale, it is a lot easier to visualise and manipulate data in a spreadsheet than through a sql client.
    - Arkanosis 7y ago
      This. Answer “pg!” without any clue of what the objective is, and you'll end up with surprises like “oh, you know, this is for a revolutionary concept where people can check in their source code at different stages of development, so that they have a history of their changes and can restore an older version if needed” or “hey, we've followed your expert recommendations but now we're facing some availability issue after a link to our shiny new search engine made the front page of HN and Slashdot”. Migrating from pg to git or SOLR is not really enjoyable, and you can't reuse much of what you've done (unlike when migrating one SQL database to another).