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

Databases in 2021: A Year in Review

ottertune.com

Post reply on HN
Print view View original

71–80 of 136 posts

Re: Databases in 2021: A Year in Review

#71

Post by p_l »

newlisp wrote: post #31
why-el wrote: post #4

Postgres's dominance is well deserved, of course. My only concerns with it, both are actively worked on, are bloat management (significant for update heavy workloads and programmers used to the MySQL model of rollback segments) and the scaling of concurrency (going over 500 connections). Bloat was taken over by Cybertec[1] after stalling for a bit and is funded (yay), while concurrency was also enhanced out of Micros…

Another concern, no temporal tables, don't businesses demand this feature?

Interestingly enough, Postgres used to have time travel in tables before MVCC transactions were added. Apparently it wasn't exactly used feature.

Re: Databases in 2021: A Year in Review

#72

Post by skunkworker »

hu3 wrote: post #6

I expected more mentions of Vitess, which honestly looks like some kind of alien black magic from what I saw while consulting for a client this year. But I guess not much else happened to it other than PlanetScale.

I would love to use Vitess, but it doesn’t support Postgres at the moment. And that’s a non-starter unfortunately.

Re: Databases in 2021: A Year in Review

#73

Post by InsaneOstrich »

srcreigh wrote: post #64
newlisp wrote: post #31

Earlier quoted context omitted.

Another concern, no temporal tables, don't businesses demand this feature?

What do temporal tables do that good queries don't?

Auditing of changes. We have to have a second table that stores history for any table that may need to be audited in the future

Re: Databases in 2021: A Year in Review

#74

Post by mns06 »

endisneigh wrote: post #47

I wish there was some API that abstracted the DB and all technical details and you could connect nodes to it that are specific databases with specific capabilities and it would delegate as necessary.

You might want to look into debezium. We use it to extract the change log from a generic OLTP database into Materialize, a view maintenance engine. Combining that data with event streams in Kafka is very powerful for us.

Re: Databases in 2021: A Year in Review

#75

Post by Too »

endisneigh wrote: post #47

I wish there was some API that abstracted the DB and all technical details and you could connect nodes to it that are specific databases with specific capabilities and it would delegate as necessary.

Query language and data modeling for a db highly depends on if it is relational, graph, time series, denormalized or KV. Don't think this would be possible beyond what's already available in form of ORMs. Even getting SQL dialects to agree is a challenge some times.

Re: Databases in 2021: A Year in Review

#76

Post by y4mi »

srcreigh wrote: post #66
srcreigh wrote: post #58

Earlier quoted context omitted.

Is this ranking by # of orgs using Postgres, or relative total company value using Postgres, or some even more ambiguous effectiveness metric? Answer: https://db-engines.com/en/ranking_definition

A DB system that works for professionals and doesn't require any public ecosystem of training materials won't be mentioned much in public.

thats likely why they're also including mentions in job postings in their metric

> Number of job offers, in which the system is mentioned

its not a silver bullet, but I do think its at least somewhat representative of popularity.

Re: Databases in 2021: A Year in Review

#79

Post by tpetry »

roenxi wrote: post #49
newlisp wrote: post #31

Earlier quoted context omitted.

Another concern, no temporal tables, don't businesses demand this feature?

Although temporal tables are a really good idea; it is possible to get away without them being a first class feature. They aren't hard to mimic if you can give up the guarantee of catching every detail. In an ideal world (ha ha, silly thought) the tables would be designed to be append-only anyway, or the amount of data would be significant. Both of which make temporal tables somewhat moot.

They are really easy to mimic in PostgreSQL with range types (tstzrange) and an exclusion constraint, so now overlapping values are allowed. I guess they will not add it to the core if a developer can add support to them so easy.

Re: Databases in 2021: A Year in Review

#80

Post by ivank »

newlisp wrote: post #31
why-el wrote: post #4

Postgres's dominance is well deserved, of course. My only concerns with it, both are actively worked on, are bloat management (significant for update heavy workloads and programmers used to the MySQL model of rollback segments) and the scaling of concurrency (going over 500 connections). Bloat was taken over by Cybertec[1] after stalling for a bit and is funded (yay), while concurrency was also enhanced out of Micros…

Another concern, no temporal tables, don't businesses demand this feature?

I use https://github.com/xocolatl/periods for this to some success.
Post reply on HN