HackerTrans
トップ新着トレンドコメント過去質問紹介求人

redskyluan

no profile record

投稿

My Notes After Databricks Data and AI Summit 2026

zilliz.com
4 ポイント·投稿者 redskyluan·10 日前·0 コメント

Introduce Loon: lake-native storage engine behind Milvus 3.0 for AI data

zilliz.com
3 ポイント·投稿者 redskyluan·先月·0 コメント

Between Claude Code and my wife, only one enjoyed my late nights

zilliz.com
1 ポイント·投稿者 redskyluan·4 か月前·0 コメント

My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code Database Instead

zilliz.com
3 ポイント·投稿者 redskyluan·5 か月前·1 コメント

コメント

redskyluan
·5 か月前·議論
Between Claude Code and my wife, only one enjoyed my late nights — a fun take on vibe-coding obsession and hard engineering lessons.
redskyluan
·5 か月前·議論


  Maintainer of Milvus here. A few thoughts from someone who lives this every day:

  1. The free user problem is real, and AI makes it worse. We serve a massive community of free Milvus users — and we're grateful for them, they make the project what it is. But we also feel the tension MinIO is describing. You invest serious engineering effort into stability and bug fixes, and most users will never become paying customers. In the AI era this ratio only gets harder — copy with AI becomes easier than ever

  2. We need better object storage options. As a heavy consumer of object storage, Milvus needs a reliable, performant, and truly open foundation. RustFS is a solid candidate — we've been evaluating it seriously. But we'd love to see more good options emerge. If the ecosystem can't meet our needs long-term, we may have to invest in building our own.

  3. Open source licensing deserves a serious conversation. The Apache 2.0 / Hadoop-era model served us well, but cracks are showing. Cloud vendors and AI companies consume enormous amounts of open-source infrastructure, and the incentives to contribute back are weaker than ever. I don't think the answer is closing the source — but I also don't think "hope enterprises pay for support" scales forever. We need the community to have an honest conversation about what sustainable open source looks like in the AI era. MinIO's move is a symptom worth paying attention to.
redskyluan
·6 か月前·議論
Using Hierarchical Clustering significantly reduces recall; this is a solution we used and abandoned three years ago.
redskyluan
·8 か月前·議論
dude you already missed the window.

nothing is better than sqlite as a library and don't use high perforamnce as your value for a python product
redskyluan
·8 か月前·議論
I really enjoyed this article. I have a lot of appreciation for PG, but some articles tend to exaggerate its capabilities, especially when it comes to PG vectors, which can be off-putting."
redskyluan
·8 か月前·議論
check https://github.com/zilliztech/VectorDBBench
redskyluan
·10 か月前·議論
By the way, if you’re not fully satisfied with S3Vector’s write, query, or recall performance, I’d encourage you to take a look at what we’ve built with Zilliz Cloud. It may not always be the lowest-cost option, but it will definitely meet your expectations when it comes to latency and recall.
redskyluan
·10 か月前·議論
Author of this article.

Yes, I’m the founder and maintainer of the Milvus project, and also a big fan of many AWS projects, including S3, Lambda, and Aurora. Personally, I don’t consider S3Vector to be among the best products in the S3 ecosystem, though I was impressed by its excellent latency control. It’s not particularly fast, nor is it feature-rich, but it seems to embody S3’s design philosophy: being “good enough” for certain scenarios.

In contrast, the products I’ve built usually push for extreme scalability and high performance. Beyond Milvus, I’ve also been deeply involved in the development of HBase and Oracle products. I hope more people will dive into the underlying implementation of S3Vector—this kind of discussion could greatly benefit both the search and storage communities and accelerate their growth.
redskyluan
·昨年·議論
Postgres users often hit scaling issues — whether it's with LISTEN/NOTIFY, PGVector, or even basic relational queries.

For startups, Postgres is a fantastic first choice. But plan ahead: as your workload grows, you’ll likely need to migrate or augment your stack.
redskyluan
·2 年前·議論
Regarding scale, PostgreSQL may not cover all bases. Though I'm a PostgreSQL fan, I prefer specialized services for specific tasks. Using PG-based plugins could help, but a dedicated SQL-compatible database is often a better fit.

For vector retrieval, going with a database like Milvus, designed for vectors, is usually more efficient and cost-effective. Similar principles apply across domains. Is there any vectordb under PG format?

What if we've got a deeply customized distributed vector search service on PostgreSQL, that's impressive!