3 ms·
Having worked with dozens of different databases over lots of years, I can certainly say that Postgres is my go-to _default_ database over all the other relatio
by endymi0n 7y ago
Having worked with dozens of different databases over lots of years, I can certainly say that Postgres is my go-to _default_ database over all the other relational ones.
In the same way that Golang claims it's the 90% language ( https://talks.golang.org/2014/gocon-tokyo.slide#1 https://talks.golang.org/2014/gocon-tokyo.slide#1 ), I'd say Postgres is the perfect 90% database.
However, we're still using at least four other databases in production, and the reason why is that because it's doing something of everything, there are lots of niches that it doesn't fill well. It's all about tradeoffs.
If you've got a Full Text Search problem, PG is "good enough", that is until you need to index more challenging languages like Korean or need more exotic scoring functions. For that, Elastic is better.
You can do small scale analytics on PG, but at larger sizes, the transactional setup gets in the way and you're better off with BigQuery/Redshift/Snowflake.
You can scale vertical pretty big these days, but if you need linear scalability while still guaranteeing single digit ms access, you're better off with ScyllaDB.
However, there isn't a single project I wouldn't not start on a Postgres these days, that's how much I love it.
- guiriduro 7y agoI wouldn't say PostgreSQL was the analogue of golang: go's initial popular growth for being 'good enough' while being arguably oversimplified, where simplicity masks problems, under the pretence that YANGNI always applies (initial N emphasizing the Not of Aren't), seems much closer to MySQL's history. PG was driven by engineering correctness, by considering what DBAs 'Are Going to Need'. Sometimes that strictness worked against popular growth but in the end it has worked out well, as many programmers figured out they also needed it. I'd say the programming language analogue would likely be Rust, lets see in 10 years where the 90% case lies.
- KptMarchewa 7y agoRust is too complicated for 90% cases. 90% of cases are simpler with GC.
- ansible 7y agoRust is more complicated than some languages with GC. However, if you are writing some code with multi-threading (who isn't these days), then you may eventually want the help Rust gives you there as far as correctness goes.
- jfkebwjsbx 7y agoMultithreading is only needed in very few fields. Multiprocessing is way easier and works fine for most. And the majority of programmers still only need to write serial code.
- setr 7y agoAnd if not serial.. embarrassingly parallel
- jansense 7y agoI'd argue that what you're saying is true, in its current state. High-level Rust libraries take longer to write, and so they don't exist yet. As soon as Rust gets more powerful tools that abstract away the work, I suppose it might alleviate a large part of the churn.
- LunaSea 7y agoCould you expand on the issues with PostgreSQL full text search for Korean? I'b be interested to know about the limits of the full text feature.
- andrewflnr 7y agoI'm interested in why you would choose Scylla over Cassandra. Does it have advantages/differences besides performance? I remember Scylla being approximately a C++ rewrite of Cassandra, but lost track of the community opinion of them.
- manigandham 7y agoScyllaDB is far faster, more stable, and requires less config, maintenance and tuning. There's no reason to use standard Cassandra unless you need it for compatibility.
- innocentoldguy 7y agoWhat issues are you having with Korean indexing? I work with Japanese data in PostgreSQL all the time and have never noticed any issues. Japanese is more complicated that Korean, in my opinion.