Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What could a modern database do that PostgreSQL and MySQL can't

news.ycombinator.com

Post reply on HN
Print view View original

191–200 of 326 posts

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#191

Post by gigatexal »

topspin wrote: post #120
DanHulton wrote: post #60

Earlier quoted context omitted.

Consider using Postgres views! You can create a view into your data and use that for reading and writing. Then, when you need to change the underlying data model, you create a new view with the renamed column. Old clients will target the old view, new clients will target the new view. Then, when all old clients are removed, you can remove the old view safely.

"Consider using Postgres views!" The minute you create a view modifying the underlying table usually gets blocked, in many cases even for changes that have zero relevance to the view. You have to drop the view(s) to get the ALTER TABLE to go through. Absolute nightmare. Oracle, for example, does a far better job of handing this type of evolution and dependency management.

Does Postgres support a NO SCHEMA BINDING option like Redshift does for views? If so you get a view but it allows for the underlying table to change — this has advantages and disadvantages but it fixes the view/table coupling issue.

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#192

Post by spaetzleesser »

acjohnson55 wrote: post #178
dheera wrote: post #161

MongoDB: Stashing unstructured JSON data that you don't really know how you might want to query later. Also, getting up and running with an investor demo ASAP with zero technical fuss, because you have a startup idea but you're broke and can't pay your next month's rent unless you either (A) finish this demo and get that investor money next week, or (B) quit working on your idea and take the Google offer. (Yes, I've…

You can stash unstructured JSON data in Postgres just fine! https://scalegrid.io/blog/using-jsonb-in-postgresql-how-to-e...

I just wish the syntax was nicer :-(

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#194

Post by gigatexal »

taffer wrote: post #48
thom wrote: post #8

I realise I'm straying a bit from core OLTP stuff but also I think removing the historical need for a separate OLAP database is something modern systems should address. Off the top of my head: 1) Incremental materialized view maintenance, à la Materialize (bonus points for supporting even gnarly bits of SQL like window functions). 2) Really ergonomic and scalable pub/sub of some sort, à la RethinkDB. 3) Fine tuned co…

Another interesting approach is HyPer[1]. HyPer uses many new techniques to combine OLTP and OLAP in one database. For example, to achieve good OLAP performance, a columnar storage layout is used, but the columns are chunked for locality to achieve good OLTP performance at the same time. OLTP queries are executed in memory, but cold data that is not used for OLTP is automatically compressed and moved to secondary sto…

Not much one can do with Hyper as it sold the commercial license to Tableau and I can’t find any mention of an OSS version to play with anywhere on the site.

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#195

Post by BarryMilo »

zem wrote: post #140
zozbot234 wrote: post #136

Earlier quoted context omitted.

Postgres comes with the building blocks for both sharding and HA out of the box, and they're extensively discussed in the docs. You don't need proprietary addons other than as pure convenience.

don't underestimate the importance of convenience. I'm convinced one of the reasons MySQL had so much more mindshare than postgres back in the day was that it was far easier to get up and running, even if postgres might have been easier to use once everything was set up correctly.

I don't even remember choosing MySQL when I started (15 years ago). It was just so dominant, we didn't question it.

Nowadays I would still use it because I assume it is the dumbest database system and that's exactly what I need for my 1-5 user app.

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#197

Post by 5e92cb50239222b »

BarryMilo wrote: post #195
zem wrote: post #140

Earlier quoted context omitted.

don't underestimate the importance of convenience. I'm convinced one of the reasons MySQL had so much more mindshare than postgres back in the day was that it was far easier to get up and running, even if postgres might have been easier to use once everything was set up correctly.

I don't even remember choosing MySQL when I started (15 years ago). It was just so dominant, we didn't question it. Nowadays I would still use it because I assume it is the dumbest database system and that's exactly what I need for my 1-5 user app.

It still has some features over PostgreSQL that pushed me to choose it (actually MariaDB) for a new project about a year ago, namely multi-master replication. Yes, I know, terrible database and horrible feature, but it really helped in that particular domain.

I couldn't find anything decent for postgres, while MariaDB/MySQL have that built-in, with some differences in implementation. Especially for a customer who refuses to pay for his software, because there are some commercial solutions.

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#198

Post by ralusek »

calmoo wrote: post #113
mirekrusin wrote: post #33

Earlier quoted context omitted.

It always rubs me the wrong way - all those paxos/raft approaches (which are great, but...) simply elect the leader to pick writes. In that sense there is no distribution of computation at all. It's still single target that has to cruch through updates. Replication is just for reads. Are we going to have something better anytime soon? Like real distribution, when you add more servers writes distribute as well?

CAP theorem. Choose two, it's a fundamental limitation of scaling a database.

I've always found CAP theorem to be better described as:

Given the need for Partitions, you must choose between prioritizing Consistency or Availability.

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#199

Post by erik_seaberg »

Thaxll wrote: post #139
calmoo wrote: post #113

Earlier quoted context omitted.

CAP theorem. Choose two, it's a fundamental limitation of scaling a database.

Google Spanner does the three.

> The purist answer is “no” because partitions can happen and in fact have happened at Google, and during some partitions, Spanner chooses C and forfeits A. It is technically a CP system.

— https://cloud.google.com/blog/products/databases/inside-clou...

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#200

Post by User23 »

Upitor wrote: post #52
shekispeaks wrote: post #40

Automatic indexes. Adding indexes is a guessing game. It's a bit of abstraction leakage. Imagine a product engineer did not have to think about how the data is laid out on disk

What? I wouldn’t want this. How would you evne automate it? Creating the right indexes is the same as creating the right tables and columns in your data model: It depends on the business purpose and usage of the data.

Just spitballing, it sounds plausible to infer the correct index from the set of common queries.

Edit: Which I guess is basically what the sibling commenters said.

Post reply on HN