Ask HN: What is your preferred NoSQL database?
I am already using Postgres but to save some large unstructured data, I am looking at secondary NoSQL. I am not sure about using MongoDB but I like RethinkDB or CouchDB. Would like to know if any of you are using it in production despite these projects being not very actively developed or any other option apart from Graph database.
10 comments
NoSQL means two things to me: (1) schemaless(!) document store (2) sharding across multiple machines out-of-the-box.
(1) there's always a schema, it's either explicit or implicit. I find explicit to be less troublesome along the road. Sort of like static type checking--values have types, do you want to handle it at compile (sooner) or runtime (later)
(2) can be provided by NewSQL databases, e.g. CockroachDB but you will be paying upfront in latencies. Can't get away with doing N+1 queries so code has to be cleaner sooner.
(1) there's always a schema, it's either explicit or implicit. I find explicit to be less troublesome along the road. Sort of like static type checking--values have types, do you want to handle it at compile (sooner) or runtime (later)
(2) can be provided by NewSQL databases, e.g. CockroachDB but you will be paying upfront in latencies. Can't get away with doing N+1 queries so code has to be cleaner sooner.
Have you considered using Postgres with JSONB?
What charactistic of this data suggests NoSQL when structured data is in psql? Specifically do you need a distributed db?
For NoSQL, I currently use MongoDB and Elasticsearch in production. Elasticsearch was by choice, whereas MongoDB was something I inherited.
For new projects, if I'm picking NoSQL at all, I'm more likely to lean Elasticsearch, but it definitely takes longer to set up and has a much higher learning curve. And as always, it's going to heavily depend on the data and its access patterns. My default continues to be RDBMS unless there's a good reason not to, even though at this point, I actually have more experience managing MongoDB and Elasticsearch clusters.
For new projects, if I'm picking NoSQL at all, I'm more likely to lean Elasticsearch, but it definitely takes longer to set up and has a much higher learning curve. And as always, it's going to heavily depend on the data and its access patterns. My default continues to be RDBMS unless there's a good reason not to, even though at this point, I actually have more experience managing MongoDB and Elasticsearch clusters.
This might help though it’s relational: https://sqlite.org/appfileformat.html
But yeah for blobs I’d just use the file system or something like s3
But yeah for blobs I’d just use the file system or something like s3
ArangoDB - multi-model NoSQL db
Google Firestore
Mongo I guess...
Not noSQL but a nice serverless is fauna.com
Not noSQL but a nice serverless is fauna.com
NoNoSQL is my favourite. ie. SQL
Why not use the filesystem?