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

Postgres is eating the database world

medium.com

Post reply on HN
Print view View original

131–140 of 147 posts

Re: Postgres is eating the database world

#131

Post by zachmu »

atonse wrote: post #130
zachmu wrote: post #105

We're writing a postgres-compatible database that doesn't use any postgres code: https://github.com/dolthub/doltgresql/ We're doing this because our main product (Dolt) is MySQL-compatible, but a lot of people prefer postgres. Like, they really strongly prefer postgres. When figuring out how to support them, we basically had three options: 1) Foreign data wrapper. This doesn't work well because you can't use non-nati…

I can totally understand this. Your feature set isn’t compelling enough for me to switch to MySQL when, as the original article states, Postgres basically does everything under the sun, well enough that I can keep my stack simple. But if it allows me to use my existing Postgres tools, drivers, code, and knowledge then I’d consider it.

Right. We're betting there are a bunch of people like you, hence the investment.

Re: Postgres is eating the database world

#132

Post by Tostino »

djupblue wrote: post #120
vsnf wrote: post #72

Earlier quoted context omitted.

That feels a bit like hindsight talking. Linux perhaps, but were Python and Postgres really the obvious good judgement choices 25 years ago? Every other choice was poor judgement?

Around 20 years ago when I was trying to decide on what database to use my requirement were that it should store data reliably. I learned that MySQL in contrast to PostgreSQL: 1. wasn't ACID 2. didn't have foreign key constraints 3. could loose/corrupt committed data (no WAL) Despite me not knowing much about databases it seemed like an obvious choice.

Hell, 10 years ago (in a multi database project) I got bit by MySQL not supporting check constraints, but returning successfully when I ran the create check constraint statements.

Postgres has been great all around.

Re: Postgres is eating the database world

#133

Post by hans_castorp »

The_Colonel wrote: post #108
hans_castorp wrote: post #79

Earlier quoted context omitted.

> Some ancient design decisions have aged poorly, such as its one connection per process model Oracle uses the same model by default on Linux. Since 19 (or maybe earlier) it is configurable though, but the default is still one process per connection if I'm not mistaken.

It's actually quite impressive they were willing & able to make such a drastic change in such an old and conservative codebase.

Not sure how drastic it was to be honest. Under Windows, multi-threading was always the only option. So in theory, they already had code for that.

Re: Postgres is eating the database world

#135

Post by derekperkins »

Tostino wrote: post #132
djupblue wrote: post #120

Earlier quoted context omitted.

Around 20 years ago when I was trying to decide on what database to use my requirement were that it should store data reliably. I learned that MySQL in contrast to PostgreSQL: 1. wasn't ACID 2. didn't have foreign key constraints 3. could loose/corrupt committed data (no WAL) Despite me not knowing much about databases it seemed like an obvious choice.

Hell, 10 years ago (in a multi database project) I got bit by MySQL not supporting check constraints, but returning successfully when I ran the create check constraint statements. Postgres has been great all around.

It finally supports them, which is nice. It doesn't support deferred checks to the commit, like postgres, but are otherwise good. I've appreciated using it to enforce json schema at the db level

Re: Postgres is eating the database world

#136

Post by derekperkins »

riku_iki wrote: post #123
lmm wrote: post #31

Postgres is still single-node-first, and while Citus exists I'm skeptical that it can ever become as easy to administer as a true HA-first datastore. For me the reason to use something like Cassandra or Kafka was never "big data" per se, it was having true master-master fault tolerance out of the box in a way that worked with everything.

You should look at CocroachDB: it tries to be PG compatible (not there yet), but true HA-first.

At often 10x the latency and significant query compatibility issues. That's a hard pill to swallow

Re: Postgres is eating the database world

#137

Post by riku_iki »

derekperkins wrote: post #136
riku_iki wrote: post #123

Earlier quoted context omitted.

You should look at CocroachDB: it tries to be PG compatible (not there yet), but true HA-first.

At often 10x the latency and significant query compatibility issues. That's a hard pill to swallow

latency increase is likely payment for distributed consistency regardless of specific DB: doing consensus between nodes is much slower than dumping block of data on local nvme.

Re: Postgres is eating the database world

#138

Post by derekperkins »

jpalomaki wrote: post #52

I would like to keep my data in Postgres (OLTP purposes), but run analytical queries against the same datafiles in Snowflake/DuckDB fashion. The analytics part should scale independently. Often this is only needed occasionally, so scale-to-zero (like Snowflake) would be great.

You have been able to do that with DuckDB for 18 months. https://duckdb.org/2022/09/30/postgres-scanner.html

Clickhouse supports it too https://clickhouse.com/docs/en/sql-reference/table-functions...

Re: Postgres is eating the database world

#139

Post by antifa »

TOMDM wrote: post #19

Postgres is such a great tool. The feature I'd love to see added that has been kicking around the mailing list for ages now would be incremental view maintenance. Being able to keep moderately complex analysis workloads fresh in realtime would be such a boon.

MERGE was interested in 15, if that's helpful: https://www.postgresql.org/docs/current/sql-merge.html

Re: Postgres is eating the database world

#140

Post by antifa »

pg_1234 wrote: post #112
slyall wrote: post #78

Earlier quoted context omitted.

Well 25 years ago was pretty much (December 1998) when "LAMP"[1] was defined and that was originally Linux, Apache, MySQL and PHP. So Postgres and Python were not the obvious choices back then. [1] https://en.wikipedia.org/wiki/LAMP_(software_bundle)

Still, by 15 years ago Linux, Nginx, Postgres, Python had become a clearly better choice than the default LAMP stack for more complex applications.

That's how you airdrop straight into the worst of the python 2 3 fiasco, probably the worst time in history to start using python, meanwhile when Ruby on Rails and Java were probably the kings of that era.
Post reply on HN