We made Postgres writes faster, but it broke replication
42 comments
·July 21, 2025otterley
> To be an effective alternative to Elasticsearch we needed to support high ingest workloads in real time.
Why not just use OpenSearch or ElasticSearch? The tool is already in the inventory; why use a screwdriver when a chisel is needed and available?
This is another one of those “when you have a hammer, everything looks like your thumb” stories.
iw2rmb
Because you don’t need to sync and you have ACID with joins.
otterley
Is there a whole business to be had with those advantages alone? I’m curious as to who the target market is.
levkk
My last big co, we had a team of 10 who's entire job was to sync data from Postgres into Elastic. It would take weeks and fallover regularly due to traffic.
If we could have a DB that could do search and be a store of record, it would be amazing.
cryptonector
For JOINs? Absolutely! Who wants to hand-code queries at the executor level?! It's expensive!
You need a query language.
You don't necessarily need ACID, and you don't necessarily need a bunch of things that SQL RDBMSes give you, but you definitely need a QL, and it has to support a lot of what SQL supports, especially JOINs and GROUP BY w/ aggregations.
NoSQLs tend to evolve into having a QL layered on top. Just start with that if you really want to build a NoSQL.
beoberha
Interestingly enough, it looks like the team was just hacking on an open source extension and organically attracted some customers, which snowballed into raising capital. So definitely seems like there’s a market.
izietto
Because it's a whole another architectural component for data that is already there, in a tool that is made just for that lacking just of `SELECT full_text_search('kitty pictures');`
sandeepkd
There can be multiple reasons, one that I can think of right away would be to keep the stack as simple as possible until you can. Realistically speaking most of the companies do not operate at the scale where they would need the specialized tools.
AtlasBarfed
Why not the Cassandra based elastics if you need ingest?
moezd
[flagged]
rubiquity
The tradeoffs you cite aren’t about the CAP theorem. It’s more about RUM conjecture: http://daslab.seas.harvard.edu/rum-conjecture/
maxmcd
Since this is about aborted writes during VACUUM then this is likely also relevant: https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postg...
maxmcd
Hard to blame the CAP theorem since this is a problem across an interface layer. If the DB knew about the data it could manage the LSM tree without issue.
Love this style of no-fluff technical deep dive. HN needs more content like this.