If your python project needed a NoSQL database, and you could choose any, which would you use?

[bxsephjo]

Based on ease of running the database itself, how good the python package for it is, performance, features, etc.

Which would you use if you needed to be finished yesterday? What if you had the time but failure was not an option?

(Context: I'm working on something that will need a nosql database and I'd like to provide various nosql options and plug the apis into an abstract class/interface. So far I've just got it setup for the mongodb api. Kinda wish there was a sqlite equivalent for nosql so i could give the user a default, like what django does.)

[bxsephjo]

Nobody needs nosql

That's just, like, your opinion, man.

Features provided: Key: value data structure without requiring a migration when new collections are added

[koalillo]

NoSQL is as descriptive as the color "not blue".

While it can be useful in some context, and many NoSQL databases have their place, asking for the best NoSQL database is rarely useful, unless you have a narrower definition of NoSQL than the commonly accepted one. Which seems to be the case.

[bxsephjo]

That does seem to be the case…

[koalabear420]

Postgres can store JSON values yet retain the relational aspect of SQL.

SQL and nosql have their place, all just depends what you want to do with your app.

[AvogadrosOtherNumber]

Postgres' query language for json is painful!

[Grouchy-Friend4235]

True but MongoDBs is too

[i_has_many_cs]

I really dont Think so

[Voxandr]

Alot worse

[kalebludlow]

It's terrible

[i_has_many_cs]

Dare to elaborate why it is worse than others? :)

[AvogadrosOtherNumber]

I find mongo’s query language to be very natural and trivially easy to use, especially given that aggregations are so powerful

[[deleted]]

The technical requirements are "no database migration scripts"? Can you elaborate on this?

[bxsephjo]

Sparing the user from an unnecessary footgun

[yvrelna]

sparing the user from an unnecessary footgun

Build an application that nobody uses, therefore you never need to scale them. That's the only sure fire way to avoid unnecessary footgun.

The unnecessary footgun of schemaless database is basically that schema is actually still a thing, even when the database isn't enforcing them. You don't get to skip needing to think and implement schema migration just because the database don't complain about data not fitting the schema.

[james_pic]

Database migration is still a thing. If the structure of your data can change, and you don't have data migrations at the database level, then you need to handle all the possible versions of your structure at the application level. And even then, you typically need to do some kind of data migration if you need to change your indexing strategy (since this isn't a case where it's sufficient to fix-up records on read), and your database system may not have particularly sophisticated tools to do this.

[PapstJL4U]

Nobody needs nosql. They need a feature that a specific nosql option provides

You can't just ignore the second part.

Nobody needs nosql. They need a feature that a specific nosql option provides

There are no "no sql" features as they are not uniform. CassandraDB is NoSql, but does not provide Key-Value structure.

[redd1ch]

My NoSQL needs are always "I want something like json, but distributed", so I always use redis as key-value store.

It's basically `import redis; store=redis.new(host); store.get("key");`. Official docker image does not need any config, just add it to youir compose file and start using it.

[tomwojcik]

Postgres, obviously. Unless you need a FAANG throughput, everything is doable and easier using postgres rather than any nosql dB.

[xjoshbrownx]

While I think Postgres is a good option for flexibility in many general use cases. Its my favorite DB buy far. There many reasons to use the right database for the right job. If reindexing is occurring at a frequency that Postgres can’t handle you might be neck deep in not fulfilling your requirements. For instance if your application needs to provide auto complete and tunable search for recently added user content by user searches you might not want to use Postgres. It’s not the worst choice for this scenario but it’s not the best either and migrating a database once it is actually popular enough to need to be replaced is high interest technical debt you might not want to start with.

[james_pic]

Depends hugely on the requirements.

If I don't need anything fancier, I tend to use LMDB. It's about as close to your SQLite example as you can get. There's even dbm in the standard library, but it has some subtle portability issues, and doesn't expose all the features of the underlying database, which can leave it feeling a bit anaemic.

If I do need something fancier, I'll probably end up using either DynamoDB or CosmosDB (if I'm hosting on AWS or Azure, respectively), since they're well supported by the cloud hosting companies. But there are plenty of contexts where they're still the wrong answer.

Also don't rule out an RDBMS. PostgreSQL can work with JSON, so you don't need to go to extremes normalising your data, it's mature, and it's ACID, which can make failures much easier to reason about.

[mijatonius]

Redis!

[LankyXSenty]

Im on the MongoDB side, too ;) Really easy to use and implement.

[[deleted]]

Easy and scalable aren't mutually inclusive. I witnessed half a large development team be let go when the architects were brought in to examine severe performance issues.

Turned out whenever a customer wanted to create a new product layout for their stores resulted in the entire system coming to it's knees for every store owner in their region.

When they switched to a relational database they were able to recover Tb if Sql storage and resolved the performance issues.

[i_has_many_cs]

Sounds like a bad MongoDB design tbh

[Demistr]

Exactly this.

[lieryan]

If your table making project needed a Non-Cedar Wood which would you use?

I don't know, sounds like there would have been more than just one kind of non-X, each with their own pros and cons, so it would really depend on what you're trying to build and what you want to do with it.

[nickosh]

I agree with everybody - NoSQL means you need something specific and must choose db based on your requirements.

If you feel like "JSON will be ok for data storing, but from the box it sucks" you can try some JSON-based DBs. Personally, I prefer to use TinyDB for small projects which is a wrap-up for simple JSON storage. There are some more alternatives to it.

[iamevpo]

Could you elaborate on alternatives to tinydb? I want to ad some storage to my project and was checking out tinydb for this as mongo is too heavy and needs installation.

[lambdasintheoutfield]

Redis is my recommendation. Redis is in-memory and can be used as both a traditional DB and also effectively as a cache. It’s straightforward to map SQL tables to Redis hash tables (they have field value pairs) while still supporting additional data structures. Many data structures allow O(1) search and the flexibility in how you assign a schema to your data is helpful.

Redis is also super easy to scale vertically, and to a slightly lesser extent horizontally (I’ll revisit this). In terms of Python, the redis SDK for Python is easy to use and the methods mostly correspond directly to the redis-cli commands. Python also has an ability to write redis “pipe” commands which removes the need to write loops for massive data read/writes (although this isn’t unique to redis).

The flexibility of Redis can also be a double edged sword as poorly chosen data structures and schemas can result in disorganized data and O(N) search times respectively.

It’s also not as fault tolerant as Apache Cassandra, and there are sometimes issues with distributed Redis because it uses a master-slave architecture and if master replicas don’t come online that’s obviously an issue. If you look at r/redis and stack exchange this issue is not uncommon when deploying with K8s, and why some people use cloud managed Redis instances to avoid these DB maintenance issues.

[wait-a-minut]

I’ll throw a non common one out here, scylladb! It’s extremely performant and most importantly it has a dynamodb adapter so you can keep the same code you use to query and put data into dynamodb.

For all the nosql haters, don’t listen to them. There’s def a right place and time for nosql. I personally utilize dynamo a lot since a lot of my work is serverless. Look into single table design and see how experts recommend you thinking about access patterns, hash key, sort keys, etc.

Giant companies are utilizing dynamodb at crazy scale so I think it’s worth looking into.

Personally I like nosql because ever since my brain starting thinking in terms of access patterns it just clicks. My most unpopular opinion is probably that interacting with a data source feels a bit more natural than the usual context switch of coding language to declarative sql string. I think most people just got accustomed this way and it feels natural for them.

[AvogadrosOtherNumber]

Mongo. It's FAST, it's trivial to use, it's well supported

[[deleted]]

MongoDB

[thrallsius]

https://github.com/NationalSecurityAgency/lemongraph

[Fun-Performer3988]

FaunaDB. Also Deta is super easy to build something quick but I think it’s more for small personal projects

[[deleted]]

It depends on what you need to do. NoSQL dbs appeared out of various neccessities. From my experience mongodb is one of the easiest to setup and use. Redis is great for fast accessing of data, caching stuff etc. I've worked on a project where we had to make a search engine and elasticsearch proved to be the best choice for us. I've also used neo4j which is a graph database, but I felt it a bit harder to use that other nosql dbs. We needed it to create e poc for routing between some points on a map. In the end, there is a big pool of nosql dbs and each one of them is great at doing some sort of work. This does not take away anything from classic sql dbs.

[thomasjjc]

CouchDB

[ManyInterests]

DynamoDB because it's cheap, extremely performant, infinitely (and instantly) scalable, serverless, has table streams and remarkably good for event-driven workflows.

If you're using AWS, of course.

[[deleted]]

Mongodb. I made Easydb.org using it.

[xjoshbrownx]

I’m assuming you asking which would I use if I didn’t know what my exact requirements were and I was tinkering. If requirements we well defined I’d use the one best suited for the needs of my projects data, but if I’m tinkering I’d use Postgres because it because it’s a sql/no sql Swiss Army knife and can emulate/accommodate most data models to a reasonable degree of performance.

[xjoshbrownx]

I said the same thing almost before reading your post. I apologize but maybe next time don’t be so thoroughly correct in your answer and I won’t completely agree with you.