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

It's 2026, Just Use Postgres

tigerdata.com

Post reply on HN
Print view View original

141–150 of 349 posts

Re: It's 2026, Just Use Postgres

#141

Post by stephenlf »

IgorPartola wrote: post #136
olivia-banks wrote: post #5

I do agree, I don’t know why more people don’t just use Postgres. If I’m doing data exploration with lots of data (e.g., GIS, nD vectors), I’ll just spin up a Postgres.app on my macOS laptop, install what little I need, and it just works and is plenty fast for my needs. It’s a really great choice for a lot of domains. That being said, while I think Postgres is “the right tool for the job” in many cases, sometimes you…

Where I have used SQLite most successfully is really two use cases. First, I use it for data processing. Say I need to retrieve lots of data and transform it to a different setup. I could do that in something like Python but SQL is just more expressive for that and I can also create a new database, populate it with data I have, fetch new data, combine it together, export the update to a permanent data store (usually…

DuckDB via Python is my go-to for that first use case. It’s easier than ever to use Python and SQL together with Marimo notebooks.

``` uv run --with marimo marimo run --sandbox ```

and you’re ready to go.

Re: It's 2026, Just Use Postgres

#142

Post by CharlieDigital »

storus wrote: post #134

Pinecone allows hybrid search, merging dense and sparse vector embeddings that Postgres can't do AFAIK. That results in ~10% worse retrieval scores which might be the difference between making it in the business or not.

The lesson for me isn't "don't use Pinecone", but more like "did you already max out Postgres?"

In many cases, it is going to save you time by having less infra and one less risk while you're getting started. And if you find yourself outgrowing the capabilities of Pg then you look for an alternative.

Re: It's 2026, Just Use Postgres

#143

Post by quotemstr »

dimgl wrote: post #87

I've actually started moving away from Postgres to MySQL and SQLite. I don't want to have to deal with the vacuums/maintenance/footguns.

There's a fascinating gap between PostgreSQL theory and practice here. Elsewhere in this thread, I complained that PostgreSQL extensions can't do everything yet. One thing they can do, however, or ought to be able to do, is provide alternative storage engines. That's the central thing they're supposed to be especially good at providing.

So what did the VACUUM-free, undo-based MVCC storage engine project stall? https://wiki.postgresql.org/wiki/Zheap

Why is there no InnoDB for PostgreSQL?

(Maybe OrioleDB will avoid a similar fate.)

Re: It's 2026, Just Use Postgres

#144

Post by candiddevmike »

olivia-banks wrote: post #5

I do agree, I don’t know why more people don’t just use Postgres. If I’m doing data exploration with lots of data (e.g., GIS, nD vectors), I’ll just spin up a Postgres.app on my macOS laptop, install what little I need, and it just works and is plenty fast for my needs. It’s a really great choice for a lot of domains. That being said, while I think Postgres is “the right tool for the job” in many cases, sometimes you…

I wish PostgreSQL had a native vector implementation instead of using extensions. They're kind of a pain in the ass to maintain, especially with migrations.

Re: It's 2026, Just Use Postgres

#145

Post by lima »

bluepuma77 wrote: post #82

Now we only need easy self-hosted Postgres clustering for HA. Postgres seems to need additional tooling. There is Patroni, which doesn't provide container images. There is Spilo, which provides Postgres images with Patroni, but they are not really maintained. There is a timescaledb-ha image with Patroni, but no documentation how to use it. It seems the only easy way for hosting a Postgres cluster is to use CloudNativ…

Postgres is not a CP database, and even with synchronous replication, it can lose writes during network partitions. It would not pass the Jepsen test suite.

This is very hard to fix and requires significant architectural changes (like Yugabyte or Neon have done).

Re: It's 2026, Just Use Postgres

#146

Post by satvikpendem »

olivia-banks wrote: post #5

I do agree, I don’t know why more people don’t just use Postgres. If I’m doing data exploration with lots of data (e.g., GIS, nD vectors), I’ll just spin up a Postgres.app on my macOS laptop, install what little I need, and it just works and is plenty fast for my needs. It’s a really great choice for a lot of domains. That being said, while I think Postgres is “the right tool for the job” in many cases, sometimes you…

See also, PGLite: https://pglite.dev/

And Turso: https://turso.tech/

Re: It's 2026, Just Use Postgres

#147

Post by lima »

groundzeros2015 wrote: post #131
throwaway7783 wrote: post #114

Earlier quoted context omitted.

HA is not about exceeding the limits of a server. Its about still serving traffic when that best server I bought goes offline (or has failed memory chip, or a disk or... ).

Replication?

Postgres replication, even in synchronous mode, does not maintain its consistency guarantees during network partitions. It's not a CP system - I don't think it would actually pass a Jepsen test suite in a multi-node setup[1]. No amount of tooling can fix this without a consensus mechanism for transactions.

Same with MySQL and many other "traditional" databases. It tends to work out because these failures are rare and you can get pretty close with external leader election and fencing, but Postgres is NOT easy (likely impossible) to operate as a CP system according to the CAP theorem.

There are various attempts at fixing this (Yugabyte, Neon, Cockroach, TiDB, ...) which all come with various downsides.

[1]: Someone tried it with Patroni and failed miserably, https://www.binwang.me/2024-12-02-PostgreSQL-High-Availabili...

Re: It's 2026, Just Use Postgres

#149

Post by the_arun »

I am looking for a db that runs using existing json/yaml/csv files, saves data back to those files in a directory, which I can sync using Dropbox or whatever shared storage. Now I can run this db wherever I am & run the application. Postgres feels a bit more for my needs

Re: It's 2026, Just Use Postgres

#150

Post by TheRealPomax »

the_arun wrote: post #149

I am looking for a db that runs using existing json/yaml/csv files, saves data back to those files in a directory, which I can sync using Dropbox or whatever shared storage. Now I can run this db wherever I am & run the application. Postgres feels a bit more for my needs

Why? Why would separate json/yaml/csv files be better than just... syncing using postgres itself? You point `psql` to the host you need, because clearly you have internet access even on the go, and done: you don't need to sync anything, you already have remote access to the database?
Post reply on HN