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

PostgreSQL for Everything

raphaelbauer.com

Post reply on HN
Print view View original

71–80 of 286 posts

Re: PostgreSQL for Everything

#71

Post by tux3 »

fabian2k wrote: post #32
idoubtit wrote: post #18

Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency. * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. * Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations. * No need to VACUUM, which…

If you run a single application, or a few instances of the same application, you don't need an external pool and most frameworks have an internal connection pool anyway. Not sure if I'm missing anything here, but if I want case-insensitive search I simply create an index on lower(column) and use that to query. VACUUM is something you need to pay attention to at scale. And at that point you need to know your DB anyway…

>if I want case-insensitive search I simply create an index on lower(column) and use that to query

Or even pg_trgm trigram indexes, which are case-insensitive by default and support similarity search to accept typos and misspellings.

Re: PostgreSQL for Everything

#72

Post by shayonj »

Nice one re: flatbuffers in `blob` column. Have been working with flatbuffers a lot and that's a neat idea in general.

Not 100% sure about using PG for file system at scale however. I'd love to hear more on the challenges (vacuum, toast, anything else?)

Re: PostgreSQL for Everything

#73

Post by thatwasunusual »

zulux wrote: post #67
replwoacause wrote: post #7

I use SQLite for everything, and I'm perfectly happy with it. I'm aware of the concurrent writer issues, but at my scale it doesn't even matter.

Perfectly reasonable: I'm a huge PG fan, so I start everything with it, but SQLite is sane, and it generally has a happy upgrade path to PG If you need it.

It's the other way around for me: as 99% of the stuff I develop is .NET (and I use EF Core for database stuff), I can get away with SQLite for local development, prototyping (and even staging), and then just "flip a switch" for it to run on production PostgreSQL.

Both are amazing technologies.

Re: PostgreSQL for Everything

#74

Post by Thaxll »

replwoacause wrote: post #7

I use SQLite for everything, and I'm perfectly happy with it. I'm aware of the concurrent writer issues, but at my scale it doesn't even matter.

The main issue with SQLite is the very poor type system, after testing it for an app I was shocked.

Re: PostgreSQL for Everything

#77

Post by bpavuk »

thatwasunusual wrote: post #73
zulux wrote: post #67

Earlier quoted context omitted.

Perfectly reasonable: I'm a huge PG fan, so I start everything with it, but SQLite is sane, and it generally has a happy upgrade path to PG If you need it.

It's the other way around for me: as 99% of the stuff I develop is .NET (and I use EF Core for database stuff), I can get away with SQLite for local development, prototyping (and even staging), and then just "flip a switch" for it to run on production PostgreSQL. Both are amazing technologies.

EF Core is so easy to turn into a disgrace for performance, developer experience, AND build times...

Re: PostgreSQL for Everything

#78

Post by ethagnawl »

> Timescale lately released the pgvector extension, that turns your PostgreSQL into a vector database.

I don't think this is accurate and smells like an LLM hallucination to me.

From the Timescale/Tiger Data _pgvectorscale_ project's README:

> pgvectorscale builds on pgvector with higher performance embedding search and cost-efficient storage for AI applications.

I think this is where the confusion originates. I believe pgvector is primarily Andrew Kane (@ankane) and a cadre of OSS contributors.

As an aside, I've used Timescale/Tiger Data products and was very happy with them and their support. Their team was very engaged and responsive to all of our questions. They also fixed a pretty gnarly indexing bug I uncovered in pgvectorscale in an impressively short amount of time.

Re: PostgreSQL for Everything

#79

Post by dewey »

devin wrote: post #68
dewey wrote: post #61

Earlier quoted context omitted.

The point is in general for people to just consider it, often people start out on their side projects or internal company projects and commission Elastic, Redis, Postgres, Kafka before even getting started. In reality they could fit it all into Postgres for a very long time. Nobody is saying that a huge ecommerce store with complicated filtered search logic should throw away their Elasticsearch cluster and switch to…

If you actually start looking into these things, you often start looking at custom pg extensions, which means you just made the decision to "simplify" your stack by maintaining your own postgres cluster with custom extensions. This is just papering over the fact that you're increasing the complexity and saying "well it's still just postgres!" as you do it.

Not really, most popular extensions are available on GCP/AWS (https://docs.cloud.google.com/sql/docs/postgres/extensions) out of the box and there's many things that you can easily run in Postgres without extensions (Queue, KV store).

Re: PostgreSQL for Everything

#80

Post by __s »

aleks_me2 wrote: post #63

Can Partitioning be used to move data to S3 Storage, for long term archiving?

In theory yes, just need s3 fdw

I demonstrated this with ClickHouse: https://github.com/ClickHouse/pg_clickhouse/blob/main/doc/of...

We're working on a chdb based mechanism to copy to/from s3, maybe with fdw on top we can back table in s3

You can try similar things with pg_duckdb & pg_lake

Post reply on HN