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

111–120 of 326 posts

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

#111

Post by rc_mob »

zinclozenge wrote: post #22

1. Automatic backups to an S3 compatible storage, out of the box. 2. Progressive automatic scalability. As load increases or storage runs out, the DB should be able to automatically. NewSQL databases do this already. 3. Tiered storage. 4. Support streaming, stream processing, in memory data structures, etc. I feel like this is one of those weird things but I keep wishing this were possible when I work on side project…

i mean it took me just a couple hours to write script to backup postgres db to s3. not a lot of work

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

#113

Post by calmoo »

mirekrusin wrote: post #33
grobbie wrote: post #10

CockroachDB is getting a lot of interest these days. It has broad PGSQL language (and also wire I think) compatibility yet has a clustered peer architecture well suited to running in a dynamic environment like cloud or k8s. Nodes can join dynamically and it can survive them leaving dynamically as long as there's a quorum. Data is distributed across the nodes without administrator needing to make any shard rebalance t…

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.

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

#114

Post by randomdata »

masa331 wrote: post #66

This title kind of implies that PG or MySQL aren't modern or modern enough which i think is is very wrong. Look what they bring in every update. I think they are quite modern!

Postgres was more modern when it used QUEL. SQL was a big a step backwards technically (although beneficial from a marketing standpoint).

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

#115

Post by Retric »

jffry wrote: post #106
kixiQu wrote: post #100

Earlier quoted context omitted.

The title seems fair to me. Anything that's actually used has certain commitments it made earlier in its lifecycle from which it now can't deviate, even if later developments made the commitments problematic.

I think it's unfair. "Modern" is in no way equivalent to what the thread is really asking, which is what could you do if you built a new database today with all of the knowledge but none of the existing commitments of a large mainstream database.

It’s fair because these databases made trade offs for older ideas presumably for good reasons. The question isn’t what could the have done differently up to now, but rather what new ideas might designers have included if they existed back then.

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

#116

Post by jffry »

Retric wrote: post #115
jffry wrote: post #106

Earlier quoted context omitted.

I think it's unfair. "Modern" is in no way equivalent to what the thread is really asking, which is what could you do if you built a new database today with all of the knowledge but none of the existing commitments of a large mainstream database.

It’s fair because these databases made trade offs for older ideas presumably for good reasons. The question isn’t what could the have done differently up to now, but rather what new ideas might designers have included if they existed back then.

Modern software development practices and knowledge are orthogonal to feature set / compatibility guarantees. The title asks about the former and the text asks about the latter, and I don't agree it's correct to conflate the two

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

#117

Post by winrid »

jake_morrison wrote: post #77

VoltDB is a good example of rethinking relational databases for for modern technology. Traditional databases assume that everything is stored on disk, with a bit of RAM available for cacheing. VoltDB assumes that everything is stored in RAM first, using checkpointing to disk and replication to get durability. https://www.usenix.org/legacy/events/lisa11/tech/slides/ston... Have a look at Michael Stonebraker, he's a da…

Neat. Storing everything in ram and checkpointing to disk is how a lot of game servers work, too. :)

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

#118

Post by magicalhippo »

laurent92 wrote: post #78
gkoberger wrote: post #73

Oh I've been thinking a lot about this! It might not be the answer you're looking for since they're all very UX-related and not particularly database-specific, however I have a few ideas. Sometimes I feel like databases were created by people who never built a website before. Most websites are pretty similar, and databases historically have never felt (to me at least) "modern". I always feel like I'm fighting against…

What I would like best about a database would be to be in a file, in the data directory of the website. Snapshot the filesystem, snapshot the db. SSH the filesystem and the db exists elsewhere. I wouldn’t have to deal with the db at all, since it would be part of the website files. Most Wordpress sites would fit in SQLite easily. Using Wordpress would be like opening a Word document. Postgresql can’t do that, since t…

The SQLite WASM version[1] showcased here a few times does just that.

[1]: http://static.wiki/

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

#120

Post by topspin »

DanHulton wrote: post #60
zz865 wrote: post #58

My biggest problem with databases is always versioning. IE renaming a column will break old clients. If there was a way you could have multiple schema versions so you could upgrade database then clients later it would be the best. EDIT: yes thanks for the comments, views and creating and API layers and adding instead of subtracting do all work, but I believe they're all workarounds for the underlying problem. Fixing…

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.

Post reply on HN