7 ms·
> "Saving" 15 minutes of dev time because you don't know what your schema is going to look like is going to cost you orders of magnitude more time. While I agr
by quizotic 10y ago
> "Saving" 15 minutes of dev time because you don't know what your schema is going to look like is going to cost you orders of magnitude more time.
While I agree with the spirit of this, sometimes you'll never know what your schema is, because it's not under your control to begin with. That's why there are triple-stores and "document" databases and key-value stores now, and why there were deductive databases 30 years ago.
The world is wide, and there's room for more than one tool in the chest.
- tokenizerrr 10y ago> I'm not saying those use cases don't exist, I'm saying most people don't have them.
- benjiweber 10y agoPostgres is of course an excellent document store with JSONB. Its really powerful being able to create relational views backed onto data as json and vice versa.
- rodionos 10y agoThis assumes that JSON is what you want to store and query. In my experience, about 1 year ago, I couldn't get basic things out from the Puppet database.
- cageface 10y agoExactly. The arrival of JSONB in Postgres killed most of my interest in other nosql stores. It's the best of both worlds.
- Bedon292 10y agoEven those use cases can sometimes be met by an RDBMS. Postgres can outperform Mongo as a key value, or json doc store. But Mongo is what many people think of for something like that.
- quizotic 10y agoAnd for those who may not know, but appreciate irony, Mongo now uses ... wait for it ... a somewhat stripped down, key-value-ish, embedded ... RDBMS as its underlying data store. Yes friends, "it's a dessert topping AND a floor wax"
- quizotic 10y agoshould also point out that Mongo is more than a jsonb store, and postgres is, at least currently, less than a distributed, "scale-out" database. Mongo supports problems that postgres cannot currently address. period. (and I'm a huge postgres fanboi)
- philliphaydon 10y agoCould you share some of those problems? (genuinely interested)
- phamilton 10y agoHorizontal scalability. Outgrowing a single master database (writes being bottlenecked, not reads) is really painful. You can engineer around it, but spinning up another master in a multimaster DB is a really quick and easy fix (once you have tooling built out it's a matter of minutes). Sharding your Postgres DB is not a quick and easy fix. It will likely take about a month to engineer around and perform the data migration, if not longer.